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Sir: 

The Appellants submit this Appeal Brief in support of the Notice of Appeal filed on 
February 3, 2006. This Appeal is taken from the Final Rejection dated August 3, 2005, which is 
attached as Appendix B. 

I. REAL PARTY IN INTEREST 

The real party in interest for the above-identified patent application on appeal is Siemens 
Aktiengesellschaft by virtue of an Assignment recorded at the United States Patent and 
Trademark Office on August 9, 2001, at reel 012069, frames 0386-0390. 
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II. RELATED APPEALS AND INTERFERENCES 

Appellants, Appellant's legal representative and the Assignee of the above-identified 
patent application do not know of any prior or pending appeals, interferences or judicial 
proceedings which may be related to, directly affect or be directly affected by or have a bearing 
on the Board's decision with respect to the above-identified Appeal. 
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III. STATUS OF CLAIMS 

Claims 1 and 3-27 are pending in the above-identified patent application, with claims 1, 
21, 24 and 26 being the only independent claims. Claims 1 and 3-27 stand rejected. 
Accordingly, claims 1 and 3-27 are being appealed in this Brief. A copy of the appealed claims 
is attached as Appendix A. 
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IV. STATUS OF AMENDMENTS 

Claims 1, 21, 24 and 26 were amended in the previous Response to the final Office 
Action dated August 3, 2005, but only to correct minor informalities. No substantive 
amendments were made in the application after the final rejection. 
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V. SUMMARY OF CLAIMED SUBJECT MATTER 

The present invention as recited in independent claims 1, 21, 24 and 26 is directed to a 
system and apparatuses for connecting a telecommunications device to a packet-switching 
communication network that includes the use of an interface unit. The interface unit is coupled 
to both the packet-switching communications network and to the telecommunication device. 
The telecommunications device is also further communicatively coupled to a line-switching 
telecommunications network. 

In pertinent part, either the interface unit or a control unit coupled to the interface unit are 
implemented for converting at least some of the first signaling data of the packet-switching 
communications network into a second signaling data of the line-switching communications 
network. In this case, the first signaling data is used for packet-switching communications, 
while the second signaling information is used for line-switching communications. The 
converted second signaling data is then fed to the telecommunication device. This conversion 
technique can also be used for communicating signaling data from the telecommunication 
devices to an IP network. In other word, this conversion technique can involve the conversion of 
H.323 signaling data into DSS1 signaling data and vice versa. 

An important aspect of the invention is that the second signaling data [of the line- 
switching communication network] is transmitted to the packet-switching communications 
network instead of the first signaling data [of the packet-switched communication network] when 
the second signaling data cannot be converted to the first signaling data (see, Applicant's 
Application, page 14, line 17-page 15, line 15). 

Although specification citations are given in accordance with C.F.R. 1.192(c), these 
reference numerals and citations are merely examples of where support may be found in the 
specification for the terms used in this section of the Brief. There is no intention to suggest in 
any way that the terms of the claims are limited to the examples in the specification. Pointing 
out specification support for the claim terminology as is done here to comply with rule 1.192(c) 
does not in any way limit the scope of the claims to those examples from which they find 
support. Nor does this exercise provide a mechanism for circumventing the law precluding 
reading limitations into the claims from the specification. In short, the references numerals and 
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specification citations are not to be construed as claim limitations or in any way used to limit the 
scope of the claims. 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Claims 1 and 3-27 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Rose et al. (US Patent 6,396,840) in view of Ress et al. (US Patent 6,885,658). 
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VII. ARGUMENT 

A. LEGAL STANDARDS 

In making a determination that an invention is obvious, the Patent Office has the initial 
burden of establishing a prima facie case of obviousness. In re Rijckaert, 9 F.3d 1531, 1532, 28 
U.S. P.Q.2d 1955, 1956 (Fed. Cir. 1993). "If the examination at the initial stage does not produce 
a prima facie case of unpatentability, then without more the applicant is entitled to grant of the 
patent." In re Oetiker, 24 U.S.P.Q.2d 1443, 1444 (Fed. Cir. 1992). 

In order to maintain a prima facie case of obviousness under 35 U.S.C. §103, the 
Examiner must satisfy the following criteria: 1) a suggestion or motivation, either in the cited 
references themselves or in the knowledge generally available to one of ordinary skill in the art, 
to modify the references or combine their teachings to arrive at the invention; 2) a reasonable 
expectation of success at arriving at the invention, if the combination of the cited references is 
made; and 3) a teaching of suggestion of all the recited claim limitations in the combination of 
the cited references, (see MPEP 2142). 

The teaching or suggestion to make the claimed combination and the reasonable 
expectation of success must both be found in the prior art, and not based on applicant's 
disclosure. In re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991). The initial burden is 
on the examiner to provide some suggestion of the desirability of doing what the inventor has 
done. "To support the conclusion that the claimed invention is directed to obvious subject 
matter, either the references must expressly or impliedly suggest the claimed invention or the 
examiner must present a convincing line of reasoning as to why the artisan would have found the 
claimed invention to have been obvious in light of the teachings of the references." Ex parte 
Clapp, 227 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985). When the motivation to combine the 
teachings of the references is not immediately apparent, it is the duty of the examiner to explain 
why the combination of the teachings is proper. Ex parte Skinner, 2 USPQ2d 1788 (Bd. Pat. 
App. & Inter. 1986). (see MPEP 2142). 

Further, the Federal Circuit has held that it is "impermissible to use the claimed invention 
as an instruction manual or 'template' to piece together the teachings of the prior art so that the 
claimed invention is rendered obvious." In re Fritch, 23 U.S.P.Q.2d 1780, 1784 (Fed. Cir. 
1992). "One cannot use hindsight reconstruction to pick and choose among isolated disclosures 
in the prior art to deprecate the claimed invention" In re Fine, 837 F.2d 1071 (Fed. Cir. 1988). 
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Moreover, the Federal Circuit has held that "obvious to try" is not the proper standard 
under 35 U.S.C. §103. Ex parte Goldgaber, 41 U.S.P.Q.2d 1172, 1177 (Fed. Cir. 1996). "An- 
obvious-to-try situation exists when a general disclosure may pique the scientist curiosity, such 
that further investigation might be done as a result of the disclosure, but the disclosure itself does 
not contain a sufficient teaching of how to obtain the desired result, or that the claim result would 
be obtained if certain directions were pursued." In re Eli Lilly and Co., 14 U.S.P.Q.2d 1741, 
1743 (Fed. Cir. 1990). 


9 


Application No.: 09/827,487 

B. THE REJECTION UNDER 35 U.S.C. $1 03(A) IS IMPROPER BECAUSE ROSE 
ETAL. IN VIEW OF RESS ET AL. DOES NOT RENDER OBVIOUS THE CLAIMED 
INVENTION 

Claims 1 and 3-27 stand rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Rose et al. (US Patent 6,396,840) in view of Ress et al. (US Patent 6,885,658). 

The cited art, alone or in combination, fails to disclose a system or apparatuses for 
processing first and second signaling data in a communications system, which is coupled to both 
packet-switched and line-switched communications network, "wherein the second signaling data 
[of the line-switching communication network] is transmitted in the packet-switching 
communications network instead of the first signaling data [of the packet-switched 
communication network] when the second signaling data cannot be converted to the first 
signaling data." The above features of the present invention are recited in independent claim 1, 
and similarly recited in independent claims 21, 24 and 26. 

In the final Office Action, the Examiner conceded that Rose fails to teach the 
aforementioned limitations (see, Office Action, page 5). However, in the Office Action the 
Examiner relies on Ress for teaching or suggesting the above limitations, and for formulating the 
obviousness rejection. The Applicants respectfully disagree with the Examiner's interpretation 
of Ress and instead suggest that Ress also falls short of the present invention. 

Ress discloses interworking agents that communicate with each other according to a 
protocol independent format referred to as the "agent interworking protocol" (AIP). The agent 
interworking protocol represents a superset of the messaging capabilities of all protocols to be 
supported within the packet network (see, Ress, col. 6, lines 21-37). The agent networking 
protocol is used by the system of Ress to transfer message data (SIP, MGCP, H.323), and not 
signaling information or data, according to a mapped protocol. In col. 9, lines 2-30, Ress 
discloses that the internetworking relates to the protocol of the message (H.323) that is tunneled 
(i.e., not converted), and not the signaling (H.245). The agent of Ress checks to see if the 
specific signaling is available, and if so, transfers the message data in a converted or native 
format. However, if the signaling is not supported, the data is simply discarded (see, Ress, col. 
10, lines 35-41). 
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In the Advisory Action, the sections of Ress relied upon by the Examiner do not teach or 
suggest the optional (i.e., second instead of the first) sending of signaling data when line 
switched signaling data (second signaling data) cannot be converted to packet-switched data 
(first signaling data). Although Ress generally discloses signaling between the agents and a 
MGCP gateway (see, Ress, col. 11, lines 59-67), the entire disclosure of Ress is premised on the 
exchange of IP telephony protocols. In fact, line-switched signals are not even addressed. 
Furthermore, the H.245 signaling at col. 9, lines 17-30 merely teaches that message tunneling 
using H.245 signaling is accomplished by sending "H.245 indications" between two H.323 
devices, where the H.245 signaling indicates terminal capabilities of the endpoint, and the agent 
acknowledges the message (i.e., the message goes through, see, Ress, col. 12, line 57-col. 13, 
line 6). The H.245 terminal capability messages and the AIP CPG messages are then combined 
into a multipart message, where if one or the other message protocols are not supported, they will 
be discarded (see, Ress, col. 13, lines 1-6). This cited section in Ress cannot be interpreted as 
meaning that the H.245 message is being converted to AIP CPG messages to establish optional 
transmission. Furthermore, as discussed previously, both the H.245 message and AIP CPG 
messages relied on in the embodiments cited by the examiner are transmitting in the packet- 
switched network (see, Ress, col. 6, lines 44-51). 

To summarize, the Ress reference contemplates the use of a protocol-independent agent 
interworking protocol to correlate disparate protocols being used across a gateway to ultimately 
provide a protocol-neutral system. Additionally, Rose is specifically directed to routing calls 
between narrow-band and broad-band ISDN, and further provides already-translated messaging 
and signaling (see, Rose, col. 8, lines 22-36; col. 9, lines 6-22). There is simply no teaching, 
suggestion or motivation for one having ordinary skill in the art to rely on the teaching in Ress 
when considering the teaching of Rose. In fact, there is no provision in Rose whatsoever that 
would suggest the use of a protocol-neutral configuration or AIP messaging such as that taught 
in Ress, without relying on impermissible hindsight. Moreover, it is not understood how a 
configuration such as that in Ress would even be incorporated into the teaching of Rose. 

In light of the above, the Applicants respectfully submit that Examiner has not satisfied 
the criteria necessary for maintaining a prima facie case of obviousness and independent claims 
1, 21, 24 and 26 are patentable over the cited prior art. 
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VIII. CONCLUSION 

Appellants respectfully submit that claims 1 and 3-27 are non-obvious in view of the 
cited art. Accordingly, the Appellants respectfully submit that the rejections of pending claims 1 
and 3-27 are erroneous in law and fact and should be reversed by this Board. 


Respectfully submitted, 


BELL, BOYD & LLOYD LLC 



Reg. No. 48,196 
Customer No.: 29177 
Phone: (312) 807-4208 

Dated: April 21. 2006 
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APPENDIX A 


APPENDIX A 


PENDING CLAIMS ON APPEAL OF 
U.S. PATENT APPLICATION SERIAL NO. 09/646,442 

Listing of Claims; 

Claim 1. (previously presented): A system for connecting a telecommunications 
device to a packet-switching communications network, the system comprising: 

at least one telecommunications device communicatively coupled to a line-switching 
communications network; 

a packet-switching communications network, wherein first signaling data is transmitted 
between a first subscriber line and a second subscriber line of the packet-switching 
communications network; and 

an interface unit connected to both the packet-switching communications network and the 
telecommunications device, the interface unit converting at least some of the first signaling data, 
which is intended for the subscriber line using the packet-switching communications network, 
into second signaling data of the line-switching communications network, and feeding the 
second signaling data to the telecommunications device, and vice versa, 

wherein the second signaling data is transmitted to the packet-switching communications 
network instead of the first signaling data when the second signaling data cannot be converted to 
the first signaling data. 

Claim 2. (canceled). 

Claim 3. (previously presented). A system for connecting a telecommunications 
device to a packet-switching communications network as claimed in claim 1, wherein the first 
and second signaling data contain signaling messages. 

Claim 4. (previously presented): A system for connecting a telecommunications 
device to a packet-switching communications network as claimed in claim 3, wherein the 
interface unit, via an interface program, converts the signaling messages of the packet-switching 
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communications network into equivalent signaling messages of the line-switching 
communications network. 

Claim 5. (original): A system for connecting a telecommunications device to a 
packet-switching communications network as claimed in claim 4, wherein the conversion is 
carried out using equivalent signaling messages stored in a database. 

Claim 6. (original): A system for connecting a telecommunications device to a 
packet-switching communications network as claimed in claim 4, wherein the interface program 
for signaling messages to which no equivalent signaling message is assigned is transmitted using 
a data packet as user data. 

Claim 7. (original): A system for connecting a telecommunications device to a 
packet-switching communications network as claimed in claim 4, wherein the interface program 
generates messages which at least one of the packet-switching communications network and the 
line-switching communications network requires as an acknowledgement of transmitted 
signaling data. 

Claim 8. (original): A system for connecting a telecommunications device to a 
packet-switching communications network as claimed in claim 3, wherein the signaling 
messages are used to make connection setups between the first and second subscribers. 

Claim 9. (previously presented): A system for connecting a telecommunications 
device to a packet-switching communications network as claimed in claim 3 wherein the 
signaling messages are used for at least one of activating, deactivating, and registering at least 
one service feature. 

Claim 10. (original): A system for connecting a telecommunications device to a 
packet-switching communications network as claimed in claim 9, wherein the service feature 
comprises at least one of call pick-up, three-way conferencing, large-scale conferencing, holding, 
displaying of toll information, a closed user group, call number identification, automatic callback 
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when busy, automatic callback when no response, call barring, an indication of call waiting and 
call transfer. 

Claim 11. (original): A system for connecting a telecommunications device to a 
packet-switching communications network as claimed in claim 3, wherein the signaling 
messages are transmitted in the packet-switching communications network independently of user 
connections. 

Claim 12. (previously presented): A system for connecting a telecommunications 
device to a packet-switching communications network as claimed in claim 3, wherein the 
signaling message of the line-switching communications network are DSS1 messages. 

Claim 13. (original): A system for connecting a telecommunications device to a 
packet-switching communications network as claimed in claim 3, wherein the signaling 
messages of the packet-switching communications network are signaling messages of the H.225 
signaling protocol Standard. 

Claim 14. (original): A system for connecting a telecommunications device to a 
packet-switching communications network as claimed in claim 1, wherein the 
telecommunications device is at least one of an ISDN telephone, an analog telephone, an analog 
modem, an ISDN modem and an analog facsimile device. 

Claim 15. (original): A system for connecting a telecommunications device to a 
packet-switching communications network as claimed in claim 1, wherein the 
telecommunications device is a private branch exchange. 

Claim 16. (original): A system for connecting a telecommunications device to a 
packet-switching communications network as claimed in claim 1, wherein the interface unit is 
arranged in a separate physical unit. 
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Claim 17. (original): A system for connecting a telecommunications device to a 
packet-switching communications network as claimed in claim 1, wherein the interface unit is a 
module in the telecommunications unit. 

Claim 18. (original): A system for connecting a telecommunications device to a 
packet-switching communications network as claimed in claim 1, wherein a control unit of the 
interface unit automatically logs on the interface unit as a subscriber to the packet-switching 
communications network. 

Claim 19. (original): A system for connecting a telecommunications device to a 
packet-switching communications network as claimed in claim 1, wherein the interface unit has a 
control unit which converts the data using at least one program module. 

Claim 20. (original): A system for connecting a telecommunications device to a 
packet-switching communications network as claimed in claim 1, wherein the packet-switching 
communications network is a network based on an Internet protocol. 

Claim 21. (previously presented): An interface unit which is communicatively 
coupled to both a packet-switching communications network and to a telecommunications device 
that is further communicatively coupled to a line-switching telecommunications network, 
comprising: 

a control unit which converts at least one item of signaling information of the packet- 
switching communications network into a second item of signaling information of a line- 
switching communications network and feeds it to the telecommunications device, and vice 
versa, 

wherein the second item of signaling information is transmitted to the packet-switching 
communications network instead of the first item of signaling information when the second item 
of signaling information cannot be converted to the first item. 
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Claim 22. (original): An interface unit as claimed in claim 21, wherein the interface 
unit is used to connect a communications terminal to the packet-switching communications 
network. 

Claim 23. (original): An interface unit as claimed in claim 21, wherein the interface 
unit is used to connect a private branch exchange to the packet-switching communications 
network. 

Claim 24. (previously presented): A communications terminal, connected to a line- 
switching communications network and which is used for telecommunications, comprising: 

an interface unit, communicatively coupled to a packet-switching communications 
network and to a telecommunications device, wherein said telecommunications device is further 
communicatively coupled to a line-switching telecommunication network; 

a control unit, communicatively coupled to said interface unit that converts at least a part 
of a first item of signaling information of the packet-switching communications network into a 
second item of signaling information of a line-switching communications network and feeds it to 
the telecommunications device, and vice versa, 

wherein the second item of signaling information is transmitted to the packet-switching 
communications network instead of the at least a part of the first item of signaling information 
when the second item of signaling information cannot be converted to the first item. 

Claim 25. (original): A communications terminal as claimed in claim 24, wherein 
the interface unit is a module of the communications terminal. 

Claim 26. (previously presented): A private branch exchange, connected to a line- 
switching communications network and which is used for telecommunications, comprising: 

an interface unit which is communicatively coupled to both to a packet-switching 
communications network and to a telecommunications device, wherein said telecommunications 
device is further communicatively coupled to a line-switching telecommunications network; 

a control unit, communicatively coupled to said interface unit that converts at least a part 
of a first item of signaling information of the packet-switching communications network into a 
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second item of signaling information of a line-switching communications network and feeds it to 
the telecommunications device, and vice versa, wherein the interface unit is used to connect the 
private branch exchange to the packet-switching communications network, 

wherein the second item of signaling information is transmitted to the packet-switching 
communications network instead of the at least a part of first item of signaling information when 
the second item of signaling information cannot be converted to the first item. 

Claim 27. (original): A private branch exchange as claimed in claim 26, wherein the 
interface unit is a module of the private branch exchange. 
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5) D Claim(s) is/are allowed. 
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Art Unit: 2666 

DETAILED ACTION 
Information Disclosure Statement 

1 . The information disclosure statement (IDS) submitted on 9/9/2002 is in 
compliance with the provisions of 37 CFR 1 .97. Accordingly, the examiner has 
considered the information disclosure statement. 

Drawings 

2. Replacement drawings were received on 5/16/2005. These drawings are 
acceptable and have been entered. 

Claim Objections 

3. Claims 1, 21, 24, and 26 are objected to because of the following 
informalities: 

Regarding claim 1, on line 8, the word "to" after the word "both" is not 
needed. Also, on line 9, the word "to" after the word "and" is not needed. Also, 
on line 13, there is some confusion regarding the phrase "the second data". It is 
believed that this phrase should be "the second signaling data". Also, on line 13, 
the word "in" after the word "transmitted" should be "to". Lastly, on lines 14-15, 
there is some confusion regarding the phrase "the first data". It is believed that 
this phrase should be "the first signaling data". 

Regarding claim 21, on lines 8-9, there is some confusion regarding the 
phrase "the second item of signaling information". It is unclear which "item of 
signaling information" is being referred to. Also, on line 8, the word "in" after the 
word "transmitted" should be "to". Lastly, on lines 9-10, there is some confusion 
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regarding the phrase "the first item of signaling information". It is unclear which 
"item of signaling information" is being referred to. 

Regarding claim 24, on line 1, the phrase "can be connected" should be 
changed to "is connected" in order to constitute a positive limitation. Also, on line 
13, the word "in" after the word "transmitted" should be "to". Lastly, on lines 14- 
15, there is some confusion regarding the phrase "the first item of signaling 
information". It is believed that this phrase should be "the part of the first item of 
signaling information". 

Regarding claim 26, on line 1, the phrase "can be connected" should be 
changed to "is connected" in order to constitute a positive limitation. Also, on line 
13, the word "in" after the word "transmitted" should be "to". Lastly, on lines 14- 
15, there is some confusion regarding the phrase "the first item of signaling 
information". It is believed that this phrase should be "the part of the first item of 
signaling information". 

Appropriate correction is required. 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for 

all obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described 
as set forth in section 1 02 of this title, if the differences between the subject matter sought to 
be patented and the prior art are such that the subject matter as a whole would have been 
obvious at the time the invention was made to a person having ordinary skill in the art to which 
said subject matter pertains. Patentability shall not be negatived by the manner in which the 
invention was made. 

5. This application currently names joint inventors. In considering 
patentability of the claims under 35 U.S.C. 103(a), the examiner presumes that 
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the subject matter of the various claims was commonly owned at the time any 
inventions covered therein were made absent any evidence to the contrary. 
Applicant is advised of the obligation under 37 CFR 1 .56 to point out the inventor 
and invention dates of each claim that was not commonly owned at the time a 
later invention was made in order for the examiner to consider the applicability of 
35 U.S.C. 103(c) and potential 35 U.S.C. 102(e), (f) or (g) prior art under 35 
U.S.C. 103(a). 

6. Claims 1 and 3-27 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Rose et al. (U.S. 6,396,840) ("Rose") in view of Ress et al. 
(U.S. 6,885,658) ("Ress"). 

Regarding claim 1, Rose teaches an integrated system architecture in 
Figure 5 connecting subscriber terminal 119 (telecommunications device) to LAN 
10 (packet-switching network). Rose also teaches subscriber terminal 119 
(telecommunications device) that is connected to exchange 1 18 (line-switching 
network) as shown in Figure 5. 

Rose also teaches LAN 10 (packet-switching communications network) of 
Figure 5 that communicates with multi-media endpoint 110 (second subscriber 
line). Rose also teaches gateway interface 1 12 (interface unit) of Figure 5 
connected to both LAN 10 (packet-switching network) and subscriber terminal 
119 (telecommunications device). 

Rose also teaches gateway interface 1 1 2 of Figure 6 that translates H .225 
call signaling (first signaling data) from LAN 10 into DSS1 broadband format 
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(second signaling data) for onward routing as spoken of on column 8, lines 53- 
65. 

Rose fails to teach where the second signaling data is transmitted to the 
packet-switching communications network instead of the first signaling data when 
the second signaling data cannot be converted to the first signaling data. 

However, Ress teaches a method of protocol interworking where message 
tunneling is used to transfer a native protocol message (second signaling data) 
from one protocol agent to another protocol agent without converting to and from 
the agent interworking protocol (first signaling) in the case that the native protocol 
message does not map to the other agent protocol as spoken of on column 9, 
lines 6-16. 

At the time of the invention, it would have been obvious to someone 
skilled in the art to combine the tunneling teachings of Ress with the interworking 
teachings of Rose in order to communicate messages or parameters which do 
not map to any other agent protocols, but provide added value for a call between 
two devices as spoken of on column 9, lines 6-16 of Ress. 

Regarding claim 3, Rose further teaches H.225 RAS 22, H.225 call 
signaling 14, and H.245 negotiation control 26 (first signaling data) as well as call 
signaling 114 (second signaling data) shown in Figure 6 and spoken of on 
column 8, lines 53-59. 

Regarding claim 4, Rose further teaches gateway interface 112 (interface 
unit) of Figure 6 that translates incoming H.225 call signaling (signaling 
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messages) from LAN 10 (packet network) into DSS1 broadband format (signaling 
messages) for onward routing as spoken of on column 8, lines 53-65. 

Regarding claim 5, Rose further teaches memory 154 of gateway interface 
1 12 of Figure 6 that contains look-up tables (database) associated with signaling 
protocol translation schemes used to translate LAN signaling to 
narrowband/broadband signaling as spoken of on column 8, line 66 - column 9, 
line 5. 

Regarding claim 6, Rose further teaches gateway interface 1 12 of Figure 
6 that translates incoming H.225 call signaling (signaling messages) from LAN 10 
(packet network) into DSS1 broadband format (signaling messages) for onward 
routing as spoken of on column 8, lines 53-65. 

Regarding claim 7, Rose further teaches a message (acknowledgement) 
confirming the trunk circuit identity sent from next exchange 1 18 to call handler 
1 16 in response to a setup signaling message sent from call handler 1 16 to next 
exchange 118 as spoken of on column 10, lines 24-36. 

Regarding claim 8, Rose further teaches call signaling messages 114 that 
are used to set-up and clear-down calls as spoken of on column 7, lines 53-56. 

Regarding claim 9, Rose further teaches the H.225 RAS (registering, 
admission, and status) signaling shown in Figure 6. 

Regarding claim 10, Rose further teaches call signaling information 114 
containing an address of a called party (call number identification) as spoken of 
on column 9, lines 13-18. 
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Regarding claim 11, Rose further teaches gateway interface 1 12 of Figure 
6 that translates incoming H.225 call signaling (signaling messages) from LAN 10 
(packet network) Into DSS1 broadband format (signaling messages) for onward 
routing as spoken of on column 8, lines 53-65. 

Regarding claim 12, Rose further teaches the DSS1 signaling format 
spoken of on column 8, lines 53-59. 

Regarding claim 13, Rose further teaches the H.225 RAS 22 and H.225.0 
call signaling 14 spoken of on column 8, lines 44-49. 

Regarding claim 14, Rose further teaches subscriber terminal 1 19 of 
Figure 5 that utilizes ISDN broadband communication as spoken of on column 7, 
lines 50-62. 

Regarding claim 15, Rose further teaches the exchange 118 shown in 
Figure 5. 

Regarding claim 16, Rose further teaches gateway interface 1 12 shown in 
Figure 5. 

Regarding claim 17, Rose further teaches gateway interface 112 shown in 
Figure 5. 

Regarding claim 18, Rose further teaches the gateway interface 112 
operating as a subscriber as spoken of on column 12, lines 11-16. 

Regarding claim 19, Rose further teaches gateway interface 112 shown in 
Figure 5. 

Regarding claim 20, Rose further teaches the H.225 RAS 22 and H.225.0 
call signaling 14 spoken of on column 8, lines 44-49. 
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Regarding claim 21, Rose teaches gateway interface 112 (interface unit) 
of Figure 5 connected to both LAN 10 (packet-switching network) and subscriber 
terminal 119 (telecommunications device) that is further connected to exchange 
118 (line-switching network) as shown in Figure 5. 

Rose also teaches processor 152 (control unit) of gateway interface 1 12 of 
Figure 6 that translates incoming H.225 call signaling (signaling information) from 
LAN 10 (packet network) into DSS1 broadband format (signaling information) for 
onward routing as spoken of on column 8, lines 53-65. 

Rose fails to teach where the second signaling data is transmitted to the 
packet-switching communications network instead of the first signaling data when 
the second signaling data cannot be converted to the first signaling data. 

However; Ress teaches a method of protocol interworking where message 
tunneling is used to transfer a native protocol message (second signaling data) 
from one protocol agent to another protocol agent without converting to and from 
the agent interworking protocol (first signaling) in the case that the native protocol 
message does not map to the other agent protocol as spoken of on column 9, 
lines 6-16. 

At the time of the invention, it would have been obvious to someone 
skilled in the art to combine the tunneling teachings of Ress with the interworking 
teachings of Rose in order to communicate messages or parameters which do 
not map to any other agent protocols, but provide added value for a call between 
two devices as spoken of on column 9, lines 6-16 of Ress. 
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Regarding claim 22, Rose further teaches gateway interface 112 (interface 
unit) of Figure 5 connected to both LAN 10 (packet-switching network) and 
subscriber terminal 1 19 (terminal). 

Regarding claim 23, Rose further teaches gateway interface 112 (interface 
unit) of Figure 5 connected to both LAN 10 (packet-switching network) and 
exchange 118. 

Regarding claim 24, Rose teaches gateway interface 112 (interface unit) 
of Figure 5 connected to both LAN 10 (packet-switching network) and subscriber 
terminal 119 (telecommunications device) that is further connected to exchange 
118 (line-switching network) as shown in Figure 5. 

Rose also teaches processor 152 (control unit) of gateway interface 1 12 of 
Figure 6 that translates incoming H.225 call signaling (signaling information) from 
LAN 10 (packet network) into DSS1 broadband format (signaling information) for 
onward routing as spoken of on column 8, lines 53-65. 

Rose fails to teach where the second signaling data is transmitted to the 
packet-switching communications network instead of the first signaling data when 
the second signaling data cannot be converted to the first signaling data. 

However, Ress teaches a method of protocol interworking where message 
tunneling is used to transfer a native protocol message (second signaling data) 
from one protocol agent to another protocol agent without converting to and from 
the agent interworking protocol (first signaling) in the case that the native protocol 
message does not map to the other agent protocol as spoken of on column 9, 
lines 6-16. 
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At the time of the invention, it would have been obvious to someone 
skilled in the art to combine the tunneling teachings of Ress with the interworking 
teachings of Rose in order to communicate messages or parameters which do 
not map to any other agent protocols, but provide added value for a call between 
two devices as spoken of on column 9, lines 6-16 of Ress. 

Regarding claim 25, Rose further teaches gateway interface 112 shown in 
Figure 5. 

Regarding claim 26, Rose teaches exchange 142 (private branch 
exchange) of Figure 5 connected to exchange 118 (line-switching network). 

Rose also teaches gateway interface 1 12 (interface unit) of Figure 5 
connected to both LAN 10 (packet-switching network) and subscriber terminal 
1 19 (telecommunications device) that is further connected to exchange 118 (line- 
switching network) as shown in Figure 5. 

Rose also teaches processor 152 (control unit) of gateway interface 1 12 of 
Figure 6 that translates incoming H.225 call signaling (signaling information) from 
LAN 10 (packet network) into DSS1 broadband format (signaling information) for 
onward routing as spoken of on column 8, lines 53-65. 

Rose also teaches gateway interface 112 (interface unit) of Figure 5 
connected to both LAN 10 (packet-switching network) and exchange 118. 

Rose fails to teach where the second signaling data is transmitted to the 
packet-switching communications network instead of the first signaling data when 
the second signaling data cannot be converted to the first signaling data. 
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However, Ress teaches a method of protocol interworking where message 
tunneling is used to transfer a native protocol message (second signaling data) 
from one protocol agent to another protocol agent without converting to and from 
the agent interworking protocol (first signaling) in the case that the native protocol 
message does not map to the other agent protocol as spoken of on column 9, 
lines 6-16. 

At the time of the invention, it would have been obvious to someone 
skilled in the art to combine the tunneling teachings of Ress with the interworking 
teachings of Rose in order to communicate messages or parameters which do 
not map to any other agent protocols, but provide added value for a call between 
two devices as spoken of on column 9, lines 6-16 of Ress. 

Regarding claim 27, Rose further teaches gateway interface 1 12 shown in 
Figure 5 contained within exchange 142. 

Response to Arguments 

7. Applicant's arguments with respect to amended claims 1, 21, 24, and 26 
have been considered but are moot in view of the new ground(s) of rejection 
provided above. 

Conclusion 

8. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. Berg et al. (U.S. 6,680,952) is another reference pertinent 
to this application. 

9. Applicant's amendment necessitated the new ground(s) of rejection 
presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. 
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See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as 
set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire 
THREE MONTHS from the mailing date of this action. In the event a first reply is 
filed within TWO MONTHS of the mailing date of this final action and the advisory 
action is not mailed until after the end of the THREE-MONTH shortened statutory 
period, then the shortened statutory period will expire on the date the advisory 
action is mailed, and any extension fee pursuant to 37 CFR 1 .136(a) will be 
calculated from the mailing date of the advisory action. In no event, however, will 
the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

Any inquiry concerning this communication or earlier communications from 
the examiner should be directed to Michael J. Moore, Jr. whose telephone 
number is (571) 272-3168. The examiner can normally be reached on Monday- 
Friday (8:30am - 5:00pm). 

If attempts to reach the examiner by telephone are unsuccessful, the 
examiner's supervisor, Seema S. Rao can be reached at (571) 272-3174. The 
fax phone number for the organization where this application or proceeding is 
assigned is 703-872-9306. 
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Information regarding the status of an application may be obtained from 
the Patent Application Information Retrieval (PAIR) system. Status information 
for published applications may be obtained from either Private PAIR or Public 
PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see http://pair- 
direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll- 
free). 


Michael J. Moore, Jr. 

Examiner 

Art Unit 2666 


mjm 



D/A'S TON 



Application/Control No. 

ApplicantfsVPatent Under 


09/827,487 

Reexamination 



BRUMMETAL 


Notice of References Cited 



Examiner 

Art Unit 



Michael J. Moore, Jr. 

2666 

Page 1 of 1 


U.S. PATENT DOCUMENTS 




Document Number 
Country Cade-Number-Kind Code 

Date 
MM-YYYY 

Name 

Classification 


A 

US-6,885,658 B1 

04-2005 

Ress et al. 

370/352 


B 

US-6,680,952 B1 

01-2004 

Berg et al. 

370/467 


C 

US- 





D 

US- 





E 

US- 











G 

US- 





H 

US- 





I 

US- 





J 

US- 





K 

US- 





L 

US- 





M 

us- 





FOREIGN PATENT DOCUMENTS 




Document Number 
Country Code-Number-Kind Code 

Date 
MM-YYYY 

Country 

Name 

Classification 


N 







O 







P 







Q 







R 







S 







T 







NON-PATENT DOCUMENTS 


Include as applicable: Author. Title Date, Publisher. Edition or Volume. Pertinent Pages) 


V 


W 


X 


U.S. Patent and Trademark OfTlca 
PTO-892 (Rev. 01-2001) 


Notice of References Cited 


Part of Paper No. 20050720 


Application No.: 09/827,487 


APPENDIX C 
U.S. Patent No. 6,396.840 ("Rose et al.") 


viii 


iiiiiuiiiijiiiiiiiiiiiirjiui 

US006396840B1 

(12) United States Patent m Patent No.: us 6,396,840 bi 

Rose et al. (45) Date of Patent: *May 28, 2002 


(54) METHOD, INTERFACE AND SYSTEM FOR 
CONNECTING COMMUNICATION TRAFFIC 
ACROSS AN INTERMEDIATE NETWORK 

(75) Inventors: Desne Jean Rose, St Albans; Roy 

Harold Mauger, Radlett, both of (GB) 

(73) Assignee: Nortel Networks Limited, St. Laurent 
(CA) 

( * ) Notice: This patent issued on a continued pros- 
ecution application filed under 37 CFR 
1.53(d), and is subject to the twenty year 
patent term provisions of 35 U.S.C. 
154(aX2). 

Subject to any disclaimer, the term of this 
patent is extended or adjusted under 35 
U.S.C. 154(b) by 0 days. 

(21) Appl. No.: 09/089,796 

(22) Filed: Jun. 3, 1998 

(30) Foreign Application Priority Data 


Jun. 6, 1997 (GB) 9711788 

(51) Int. CI. 7 H04J 3/02 

(52) U.S. CI 370/401 

(58) Field of Search 370/351, 352, 


370/401, 400, 389, 399, 397, 396, 395, 
465, 466, 468, 335, 537, 503, 229, 412, 
516, 460, 252-255, 353, 360, 364, 394, 
406, 409, 467, 469, 471, 474-476; 379/14, 
16, 95.15, 93.14, 93.07, 93.05, 93.31, 219, 
220, 225, 232, 240, 242, 229, 230, 231 


(56) References Cited 

U.S. PATENT DOCUMENTS 

5,592,477 A * 1/1997 Farris et al 370/396 

5,914,934 A * 6/1999 Rathnavelu 370/229 

5,923,659 A * 7/1999 Curry et al 370/401 

* cited by examiner 


Primary Examiner — Dang Ton 

(74) Attorney, Agent, or Firm — Lee, Mann, Smith, 
McWilliams Sweeney & Ohlson 

(57) ABSTRACT 

Interconnection of a multimedia terminal (110) of a 
narrowband, LAN-type network (10) to an exchange (118) 
and thence to an end-point (119) is orchestrated through an 
intermediate network (142), as shown in FIG. 5. A route 
(115) to the exchange (118) is initially established by a call 
handler (116) in responsive to a called party number of the 
end-point, before a connection supervisor (120), coupled to 
the call handler (116), sets up a control channel across the 
intermediate network (142). The control channel supports 
the communication of control messages between the multi- 
media terminal (110) and the end-point (119), which control 
messages are intercepted and interpreted by the connection 
supervisor (120). The connection supervisor (120) then 
establishes media paths through the intermediate network 
(142) dependent upon types of control message sent across 
the control channel, which media paths are used to transfer 
traffic components across the intermediate network. 

24 Claims, 6 Drawing Sheets 



2/15/05 EPR1.1 1-15 


U.S. Patent May 28, 2002 Sheet 1 of 6 


US 6,396,840 Bl 



2/15/05 EPR1.1 2-15 


U.S. Patent 


May 28, 2002 


Sheet 2 of 6 


US 6,396,840 Bl 


50 


Broadband User 


Enveloping 

Protocol 

Layers 


ATM Layer 


Physical Layer 


Fig. 2 



Prior Art 



J— 52 



2/15/05 EPR1.1 3-15 


U.S. Patent May 28, 2002 Sheet 3 of 6 US 6,396,840 Bl 


76 

r -/- r 
[Flow 
i Control 


66 

-L 


Virtual Path 
ID 


Virtual Channel 
ID 


70 

Payload L 
Type k 


Ik 

4- 

Check 
bits 


Fig. 3 

Prior Art 


Enveloped Payload 


T 

62 


T 


\ 

60 


96 


100 


102 


Channel 
ID 

Length 

User- 
User 

Indication 

Check 
bits 


Packet 
Header 

T 

94 


92 n 82 

^ L 


Payload 


BL 


82 

4- 


Payload 


Offset Field Seq. Parity 

I -i-y [ I 

86 88 90 


Fig. 4 

Prior Art 


2/15/05 EPR1.1 4-15 


U.S. Patent May 28, 2002 Sheet 4 of 6 US 6,396,840 Bl 



2/15/05 EPR1.1 5-15 


U.S. Patent May 28, 2002 Sheet 5 of 6 US 6,396,840 Bl 


J112 


22 


•225 RAS 


% 

V H-225.0 


Call Signalling 


H-245 


26 

V _ 

Negotiation Control 

2a 


V. 


Audio, 


30s 


Video 


32 


150 


Gateway 
Interface 


LAN 

I 

N 

T 
E 
R 
F 
A 
C 
E 


T 


A-J\ 

w 


i5r 


Processor 


Call 
Sig 
Inter- 
face 


Memory 


ATMY 
VC. 
Inter- 
face 


,-156 


Fig. 6 


2/15/05 EPR1.1 6-15 


U.S. Patent May 28, 2002 Sheet 6 of 6 US 6,396,840 Bl 


At gateway interface, receive 
call set-up request from LAN 


Translate set-up request Into 
appropriate (broadband) format 


Route call select next 
exchange and select 20£ 
trunk circuit identity 


TZ-200 

Fig. 7 


Select appropriate (first) 
mini-channel for H-245 / — 206 
control 


Send call signalling message, 
pertaining to trunk circuit, to -f- — 208 
next exchange 


Convert H-245 control messages received from LAN. / 
Send converted messages over first mini-channel, 210 
Reverse process applicable for communication to LAN / 


Set-up further mini-channels for 

audio/video and/or data traffic using 

H-245 control messages in first mini-channel 


-212 


Envelope received LAN traffic pockets from LAN streams, 
segment into mini-pockets, and send over mini-channels 


Receive mini-packets from mini-channels, / 
assemble into LAN traffic pockets and send A— 21 6 
over relevant LAN streams J 


Receive release call signalling , 
messages, and clear-down call T — 218 


7- 


2/15/05 EPR1.1 7-15 


US 6,396,840 Bl 


1 

METHOD, INTERFACE AND SYSTEM FOR 
CONNECTING COMMUNICATION TRAFFIC 
ACROSS AN INTERMEDIATE NETWORK 

This application claims priority from United Kingdom 5 
Application No.: 97117881 filed Jun. 6, 1997 in the name of 
Northern Telecom Limited. 

BACKGROUND OF THE INVENTION 
This invention relates, generally, to a communication 10 
system architecture and operating protocol therefor, and is 
particularly, but not exclusively, applicable to an interface 
arrangement that integrates a local area network (LAN), 
typically operating in a wide-band context, with a broadband 
virtual circuit-switched system, such as envisaged and 15 
implemented in Asynchronous Transmission Mode (ATM) 
networks. 

SUMMARY OF THE PRIOR ART 
Telephony systems have evolved from simplistic hard- 20 
wired interconnected networks to broadband, high capacity 
systems that support multimedia, multi-mode communica- 
tion devices on local area networks (LANS) and packet- 
switched communication systems. Indeed, instead of having 
to rely entirely on dedicated land-line infrastructure, present 25 
day technologies now occupy virtual channel environments 
in both the radio frequency and land-line domains. 

The designers of today's narrowband communication 
systems, which typically employ pulse code modulation at a 3Q 
data rate of 64 kilo-bits per second (kbps), are presently 
considering the adaptation and development of these nar- 
rowband communication systems to support a migration to 
a multimedia environment having data rates of two (2) 
Mega-bits per second (Mbps) and beyond. As will be 35 
understood, the requirement for migration arises as a direct 
consequence of the vast costs involved in deploying global 
communication systems, with ATM being touted as provid- 
ing a low cost and simple package that is capable of 
supporting migration from narrowband (or wide-band) to 4Q 
broadband applications (principally in the intervening 
period before the full deployment of a free-standing Uni- 
versal Mobile Telecommunication System (UMTS), for 
example). 

It has also been necessary for designers to consider and 4S 
anticipate the extensive and elaborate requirements for 
future control signalling and call management techniques. In 
this respect, new signalling schemes, such as AAL-2 nego- 
tiation procedures, have been developed to provide robust, 
high bandwidth communications at high data rates, while 50 
designers have also been keen to define system architectures 
in terms of "stacks" that comprise discrete layers of infra- 
structure or signalling protocols that each add functionality, 
capacity or control over a preceding layer in the stack. 

The problems faced by system designers are further 55 
exacerbated by the fact that, to date, the various different 
forms of communication system, e.g. ATM, LANs and 
cellular radiotelephone schemes, operate distinct signalling 
and transport protocols that are incompatible on a network- 
to-network basis. 60 

GB-A-2311690 describes the merging of two networks in 
which a telephone subsystem is connected to a packet- 
switched broadband backbone and in which telephony is 
added to the backbone without interfering with packetised 
data. GB-A-2309362 is a mechanism for interconnecting 65 
broadband and narrowband networks and is generally 
related to the present field of the present invention. 


2 

WO 96/06492 is an arrangement for supplying local 
network emulation service over a public connectionless 
ATM network. More specifically, a server acts as an address 
resolver and as a relay for routing traffic. SynOptics U.S. 
Pat. No. 5,420,858 describes the segmentation and 
re-assembly of information between non-ATM messages 
and ATM cells. 

U.S. Pat. No. 5528590 describes the transfer of data 
between an ATM-UNI interface and an ATM-LAN interface 
in a manner such that the ATM-UNI interface recognises 
frames and assembles and ATM cells into these frames. 
More particularly, the system can determine whether or not 
there is enough capacity on the LAN interface for the frame, 
and only if there is enough capacity is the frame transferred 
via a ATM switch to the ATM-LAN interface and then 
onwards to the LAN. 

It is therefore clearly desirable to design and produce a 
communication system architecture that supports varying 
types of present-day communication network, with the com- 
munication system architecture at least possessing an inter- 
face that has the capability of handling broadband signalling 
and transport schemes and which also contemplates the 
interconnection of LAN or WAN architectures to such 
broadband networks. 

SUMMARY OF THE INVENTION 

In a first aspect of the present invention there is provided 
a method of connecting a first network to a second network 
via an intermediate network, the first network and second 
network using a set of control messages to control media 
paths between the first network and the second network, the 
method comprising the steps of: establishing a control 
channel across the intermediate network to carry the set of 
control messages; intercepting the set of control messages in 
the intermediate network and determining a requirement for 
media paths in response thereto; in response to the 
determination, setting up media paths in the intermediate 
network to connect paths to carry media traffic between the 
first network and the second network. 

In another aspect of the present invention there is pro- 
vided a method of connecting communication traffic com- 
prised of a plurality traffic components across a broadband 
network from a local area network, the method comprising 
the steps of: in the local area network, generating control 
messages for controlling the traffic components and apply- 
ing these control messages to an interface of the broadband 
network; establishing a communication path within the 
broadband network to carry at least one of the plurality of 
traffic components; and in the broadband network, using the 
control messages to control transfer of the plurality of traffic 
components over the communication path. 

In another aspect of the present invention there is pro- 
vided a method of interconnecting communication traffic 
across a broadband network from a local area network 
(LAN), the broadband network having a transfer protocol 
that supports mini-channels in a virtual circuit-switched 
environment, the LAN (10) providing the communication 
traffic as LAN streams to an interface of the broadband 
network, the method comprising the step of mapping the 
LAN streams to the mini-channels. 

In a preferred embodiment, the LAN streams include 
audio, video, data and control streams, and the method 
further comprising the step of interpreting the control 
streams to set-up mini-channels used to carry at least one of 
an audio, video and a data communication. 

In yet another aspect of the present invention there is 
provided a connection supervisor for orchestrating the com- 
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munication of traffic components between first and second 
networks via an intermediate network, the connection super- 
visor responsive to control messages communicated 
between the first and second networks, the connection 
supervisor including: means for setting-up a communication 5 
path for carrying the control messages across the interme- 
diate network; means for determining types of control 
message sent across the communication path; and means for 
establishing media paths dependent upon types of control 
message sent across the communication path, the media 10 
paths arranged to transfer the traffic components across the 
intermediate network. 

In still yet another aspect of the present invention there is 
provided a communication node having a gateway that 
provides an interfaces to a first end-point in a network, the is 
first end-point arranged to initiate a call through the com- 
munication node by sending to the gateway a called party 
number of a second end-point coupled to an exchange and 
wherein control messages are communicated between the 
first end-point and the second end-point, the communication 20 
node further comprising: a call handler coupled to the 
gateway and responsive to the called party number, the call 
handler arranged to select a route to the exchange; and a 
connection supervisor, coupled to the call handler and 
operationally responsive thereto, the connection supervisor 25 
having: i) means to set-up a control channel that supports 
transfer of the control messages between the gateway and 
the exchange in response to the call handler receiving the 
called party number; ii) means for determining types of 
control message sent across the control channel; and iii) 30 
means for establishing media paths between the gateway and 
the exchange (118) dependent upon types of control message 
sent across the control channel, the media paths arranged to 
transfer traffic components across the communication node. 

In a preferred embodiment, the communication node is a 35 
broadband network and the control channel and the media 
paths are virtual channels. 

Beneficially, the preferred embodiments of the present 
invention generally provide an ability of interconnecting a 
first LAN-compatible system (such as a WAN) through a 40 
seamless public or private broadband network (supporting 
narrowband or broadband telephony) to another LAN- 
compatible system. 

BRIEF DESCRIPTION OF THE DRAWINGS 45 

Exemplary embodiments and aspects of the present inven- 
tion will now be described with reference to the accompa- 
nying drawings, in which: 

FIG. 1 is a block diagram of a prior art local area network, 
such as implemented in an H.323 Ethernet architecture; 50 

FIG. 2 illustrates the concept of an architectural slack, 
typically employed within a prior art broadband network; 

FIG. 3 illustrates a data frame structure for a prior art 
ATM network; 55 

FIG. 4 illustrates a typical frame arrangement used for 
enveloping data into the data frame structure of FIG. 3; 

FIG. 5 is a block diagram of an integrated system 
architecture, according to a preferred embodiment of the 
present invention, for an interconnected broadband-LAN 60 
environment; 

FIG. 6 represents a block diagram of a gateway of FIG. 5, 
the gateway constructed according to the preferred embodi- 
ment of the present invention; and 

FIG. 7 is a flow diagram illustrating how, in accordance 65 
with a preferred method of the present ' 
is established within the system of FIG. 5. 


Referring to FIG. 1, there is shown a block diagram of a 
prior art local area network (LAN) 10 suitable for supporting 
an Ethernet connection regime, or the like. The LAN 10, as 
will be appreciated, operates in a bursty fashion and pro- 
vides packets of data over an H.323 signalling scheme, or 
similar messaging protocol. As will be understood, the 
H.323 signalling scheme defines the functionality of the 
multimedia terminal 12, the signalling protocols utilised 
within the LAN 10, the types of terminals suitable for use 
with the LAN 10 and the transmission protocols adopted for 
use by the multimedia terminal 12. Although, for the sake of 
clarity, only a solitary multimedia terminal 12 is shown 
connected within the LAN 10, it will be appreciated that the 
LAN 10 can support a multitude of multimedia terminals 
offering differing levels of functionality to each user thereof. 

As will be appreciated, in a LAN environment a limited 
bandwidth supports numerous packet-based communica- 
tions that vie for the available bandwidth. When using H.323 
protocols over the LAN architecture, port addresses of a first 
end point are associated with port addresses of a second end 
point, with the resultant interconnection between pairs of 
port addresses referred to (generally) as an H.323 channel. 
In this context, the term "end point" relates to a terminal, a 
gatekeeper or a gateway (the functions of which will be 
described later). Each H.323 video or audio channel can be 
a wideband channel presently supporting data up to a rate of 
2 Mbps. 

As will be understood, the multimedia terminal 12 and the 
multimedia gateway 20 each have unique port addresses 
through which communication (interconnection) is estab- 
lished. Each port address is typically comprised of the LAN 
address and a port number, with the LAN address usually 
common to a specific piece of equipment (i.e. the gateway 
20 or a multimedia terminal). 

A dedicated call signalling channel 14 couples the mul- 
timedia terminal 12 to a first multimedia gatekeeper 16, 
which first multimedia gatekeeper 16 is, in turn, coupled to 
a second multimedia gatekeeper 18 through the call signal- 
ling channel 14. The second multimedia gatekeeper 18 is 
further coupled to a multimedia gateway 20 (or "multimedia 
termination point", such as a printer) through the call 
signalling channel 14. Both the first multimedia gatekeeper 
16 and the second multimedia gatekeeper 18 are, 
respectively, coupled to the multimedia terminal 12 and the 
multimedia gateway 20 via a registration, admission and 
status (RAS) channel 22-24. The call signalling channel 
uses the H.323 signalling protocol. In the context of the prior 
art, the use of either or both gatekeepers is optional and is 
included for a more complete understanding of a set-up of a 
H.323 call. 

The function of the multimedia gatekeeper, as will be 
appreciated, is principally to translate LAN addresses into 
appropriate network addresses, and to negotiate and control 
bandwidth requirements for a proposed H.323 communica- 
tion. Specifically, in response to the multimedia terminal 12 
generating an alias network address (i.e. not a LAN address, 
but something like an e-mail address), the gatekeeper oper- 
ates to translate the alias address into a usable network or 
LAN address. More particularly, a processor in the gate- 
keeper will typically access a look-up table (shown only in 
relation to the second gatekeeper 18 for clarity) to ascertain 
the usable network or LAN address, whereafter the gate- 
keeper updates the multimedia terminal 12 with the usable 
network or LAN address via the RAS 22. The network 
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address is analogous to a telephone number in a conven- 
tional telephone system, although the network address may 
be formulated in such a way that it can address multiple 
terminals simultaneously. 

It will be understood that the multimedia gatekeepers 
16-18 may be co-located with the multimedia terminal 12 
and the multimedia gateway 20, and are illustrated as 
distinct blocks for the sake of explanation. While the LAN 
is described as having a multimedia gateway 20 (that 
provides access to different networks having different sig- 
nalling protocols via a signalling channel resource 34, a 
control channel resource 36 and channels 38 that support 
audio, video and/or data), the gateway 20 could be substi- 
tuted for a second multimedia terminal or a multi-point 
control unit (namely a conference bridge). 

The LAN 10 operates with three principal signalling 
schemes for each multimedia call. The purpose and function 
of these schemes will now be described. 

Call signalling information is communicated along the 
call signalling channel 14 and is arranged, principally, to 
set-up and clear-down calls. Call signalling information 
generally includes routing information (e.g. the network or 
LAN address), acknowledge back signalling, connection 
request/release instructions and input/output port addresses. 
Assuming that a suitable network address is eventually 
output from an end point, e.g. multimedia terminal 12, the 
network address is passed along the call signalling channel 
14 and routed via at least the first multimedia gatekeeper 16 
(and probably he second multimedia gatekeeper 18) to a 
receiving end point, e.g. the multimedia gateway 20. More 
particularly, the network address is typically encoded in a 
set-up message, as will readily be appreciated, and also 
identifies the port for the negotiation control channel 26 that 
the multimedia terminal 12 intends to use. The set-up 
message, sent from the multimedia terminal 12, causes the 
receiving unit (in this example, the gateway 20) to respond 
by sending a port identification and LAN terminal address 
over the call signalling channel 14. In this way, the receiving 
unit (in this case the multimedia gateway 20) identifies to the 
multimedia terminal 12 which port the receiving unit intends 
to use for the negotiation control channel 26. As such, both 
the requesting multimedia terminal 12 and the called party 
each possess an address of a port to which communications 
on the LAN 10 are to be directed. 

Once an understanding (in terms of port usage) has been 
established between parties that are to participate in the 
communication, the call signalling channel 14 is used to 
administer overall system control, while the negotiation 
control channel 26 (established between the identified port 
addresses) is used for two principal purposes. First, the 
negotiation control channel 26 is used to communicate 
in-call channel information, such as timing information, 
channel frequency information, data rates and bandwidth 
allocations. Secondly, the negotiation control channel 26 is 
used to identify the port addresses (at all terminals) and to 
control transmissions on the audio stream 28, video stream 
30 and data stream 32. The negotiation control channel 26 
may utilise H.245 signalling or the like. 

In an alternative prior art system, namely a broadband 
network, it will be appreciated that, conceptually, the sys- 
tems architecture can be considered to comprise discrete 
architectural layers; this is illustrated in detail in FIG. 2. 
Specifically, broadband networks, such as those which uti- 
lise ATM, are derived from circuit switched telephony and 
so typically exhibit several intermediate signalling layers 
between a broadband user 50 and a physical infrastructure 
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layer 52. More particularly, there is usually at least one 
intermediate enveloping protocol layer 54 juxtaposed to the 
broadband user 50, while an ATM (packet-switched) signal- 
ling protocol layer 56 is sandwiched between the physical 

5 infrastructure layer 52 and the enveloping protocol layer 54. 
Consequently, user information provided by the broadband 
user 50 is first packaged into defined protocol envelopes (by 
the enveloping protocol layer 54), which envelopes are then 
compressed into a packet-switched format by the ATM 

10 signalling protocol layer 56. Once fully packaged, informa- 
tion can be transmitted across the broadband network 
through the physical layer 52. 

Therefore, unlike narrowband networks, i.e. circuit- 
switched communications having a fixed amount of band- 

15 width per channel, that provide a continuous transmission of 
information (even in the context of time division multi- 
plexed communication), a broadband network utilises a 
transfer protocol in which virtual channels are circuit- 
switched and which provides a provisioned (but varying) 

20 bandwidth. Broadband networks can utilise ATM and 
AAL-2 (ATM Adaptation Layer 2); the latter is a subset of 
ATM that provides switching at a virtual sub-channel level 
in an ATM environment. Other protocols used within ATM 
include AAL-1 and AAL-5. AAL-1 is an ATM adaptation 

25 protocol originally targeted at constant bit rate (CBR) traffic, 
e.g. voice or video, and is applicable to data rates equal to 
or exceeding sixty-four kbps. AAL-5 provides a capability 
of data, voice and video transmissions to work stations, and 
is therefore particularly applicable to multimedia commu- 

30 nication systems. AAL-5 segments long data structures into 
many cells, with a data structure conceivably exceeding 
fifteen hundred octets in length. 

Turning now to FIG. 3, there is shown basic cell frame 
structure 60 of a prior art broadband network. For the 

35 purpose of explanation, if we now consider the data frame 
structure 60 as being suitable for ATM transmission, the data 
frame structure 60 comprises a header 62 of control infor- 
mation and an enveloped payload 64. The header 62 com- 
prises a virtual path identifier 66 and a virtual channel 

40 identifier 68 that together co-operate to identify a circuit- 
switched path (i.e. a virtual channel) through the broadband 
network. The circuit-switched path is therefore set at the 
beginning of a call and only released at the end of the call. 
The header 62 further includes an indication of payload type 

45 70, and an indication termed cell loss priority 72 that 
stipulates whether the communication on the virtual channel 
can be dropped to support higher priority communications. 
As will be appreciated, there is a finite amount of capacity 
offered by the broadband network and so it may occasionally 

50 be necessary to consider the voluntary release of channel 
resources. Finally, the header 62 includes check-bits for 
error detection and correction, although the header 62 may 
optionally include dedicated flow control bits 76 used in 
quasi-broadband systems to enhance data rate capacity over 

55 existing communication resources, e.g. by superimposing 
high frequency channels over an existing two-wire scheme. 
More particularly, the generic flow control bits act as nego- 
tiation bits and request the assignment of bandwidth, for 
example, from a system controller (not shown). 

60 Use of this form of packet-switched structure therefore 
allows interleaving of packets across a shared physical 
resource, albeit that a virtual channel used for the commu- 
nication is unique to that communication. The enveloped 
payload 64, which is of fixed length, will now be described 

65 in more detail in relation to FIG. 4 in which there is shown 
a typical mechanism by which data is "nested" within the 
payload envelope 64 of FIG. 3. Particularly, data that is 
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ultimately to be nested within the payload envelope 64 can 
vary in length, and can be comprised from distinct data 
portions. Indeed, a combination of the individual data por- 
tions can produce a data string having an overall length that 
exceeds the length of the payload envelope 64. 
Consequently, the data may be encoded using known tech- 
niques so as to optimise nesting of the data into the payload 
envelope 64. 

In relation to an AAL-2 protocol data unit (PDU) 80, data 
82 is preceded by a start-field octet 84 comprising an offset 
field 86, a sequence number 88 and parity bit 90. 
Alternatively, with respect to an AAL-2 service data unit 
(SDU) 92, the data 82 (which, in this instance, usually varies 
in length) is preceded by a packet header 94 comprising a 
channel identifier 96, a length indicator 98, a user-to-user 
indication 100 and check bits 102. The channel identifier 96 
identifies a "mini-channel" that uniquely supports a solitary 
communication. As such, more than one mini-channel can 
be nested or interleaved within a single enveloped ATM cell 
payload 64 of FIG. 3. The length indicator 98 identifies the 
length of the data portion. The functions of the constituent 
parts of the packet header 94 are detailed in ITU standards 
document 1.363.2 

As will now be appreciated, the exemplary combination 
of FIG. 3 and FIG. 4 demonstrate the stack concept illus- 
trated in FIG. 2. The PDU and SDU layers for AAL-1 and 
AAL-5 vary from the structure of AAL-2, but both form 
stacks within ATM in a similar fashion to that described 
above, as will be readily appreciated. 

Referring now to FIG. 5, a preferred embodiment of the 
present invention is shown. The present invention provides 
a mechanism for the interconnection of a LAN to a broad- 
band network, perhaps implemented using ATM. In relation 
to the figure, elements common with the prior art contain 
identical reference numerals to those of the earlier drawing 

The LAN 10, as previously described, provides a capa- 
bility of interconnecting communication devices (i.e. mul- 
timedia endpoints 110), such as computers (having Internet 
capabilities) and multimedia terminals 12 and other multi- 
media devices. As in a conventional system, the LAN 10 
may also support a gatekeeper 16. It will be appreciated that 
a communication resource 111, coupled to a gateway inter- 
face circuit 112, supports the transmission of RAS bits and 
provides a dedicated call signalling channel, a dedicated 
negotiation control channel and audio, video and data 
streams (as previously described and shown in relation to 
FIG. 2, albeit not specifically shown in this drawing figure). 

The gateway interface circuit 112 couples call signalling 
messages 114 to a call handler 116, typically arranged to 
support an integrated service digital network (ISDN) meth- 
odology (either narrowband, broadband or a hybrid). The 
call signalling messages 114 are used to set-up and clear- 
down calls, and are also used to identify multimedia terminal 
addresses and the like. The call handler 116 is, in turn, 
coupled to a succession of other exchanges 118 through a 
semi-permanent call signalling channel 115. At least one 
subscriber terminal 119 is coupled to each other exchange, 
with the subscriber terminal 119 having a unique address. 
The connection supervisor 120 is connected through a 
control line 124 to the call handler 116. 

The connection supervisor 120 is arranged to supervise 
the control of both a mini-channel switch 126 and a virtual 
channel switch 128 via control lines 130 and 132, respec- 
tively. The virtual channel switch 128 is coupled to the 
gateway interface 112 via a first virtual channel resource 134 
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supporting (in the exemplary context of AAL-2) enveloped 
mini-channel payloads, e.g. H.245 negotiation control 
messages, and audio, video or data packets. Before provid- 
ing an output on a second channel resource 140, the virtual 

5 channel switch 128 routes the payloads received on the first 
virtual channel resource 134 through the mini-channel 
switch 126, which mini-channel switch 126 is arranged to 
optimise call transmissions ultimately output by the virtual 
channel switch 128 on the second virtual channel resource 
140. The second virtual channel resource 140 leads to the 
other exchange 118. 

The connection supervisor 120 provides a dual function. 
First, it acts to control the virtual channel switch 128 (via 
control line 132), and the mini-channel switch 126 (via 

j5 control line 130). Second, the connection supervisor 120 
also functions to receive, process and generate H.245 mes- 
sages for H.323 calls. In this latter respect, H.245 messages 
are routed between the first virtual channel resource 134 and 
the connection supervisor 120 and also between the con- 

2Q nection supervisor 120 and the second virtual channel 
resource 140, with both routings being via the virtual 
channel switch 128 and the mini-channel switch 126. 

The gateway interface 112, the call handler 116, the 
connection supervisor 120, the virtual channel switch 128 

2S and the mini-channel switch 126 constitute parts of an 
exchange (or node) 142. 

The present invention also has application in relation to 
AAL-1 and AAL-5, which operational embodiments will be 
described in more detail later. However, to support hybrid 

30 working between AAL-1, AAL-2 and AAL-5 the exchange 
142 further includes a protocol interworking processor 144 
that translates between AAL-1, AAL-2 and AAL-5. This 
protocol interworking processor 144 is coupled to the virtual 
channel switch 128. The protocol interworking processor 

35 144 is operationally responsive to the connection supervisor 
120 (via control line 145). One will appreciate that the 
mini-channel switch 126 is not required in relation to AAL-1 
and AAL-5 specific calls. H.245 messages carried on AAL-5 
instead of AAL-2 are routed solely through the virtual 

40 channel switch and through the connection supervisor; this 
connection is not shown for the sake of clarity of FIG. 5. 

FIG. 6 illustrates the structure of the gateway interface 
112 in greater detail and also according to a preferred 
embodiment of the present invention. The gateway interface 

45 112 is responsive to a LAN 10 and receives, at LAN 
interface 150, an H.225.0 RAS control channel 22, an 
H.225.0 call signalling channel 14, an H.245 negotiation 
control channel 26 and audio streams 28, video streams 30 
and data streams 32. A processor 152, coupled to a memory 

5 0 device 154, controls the routing of the various input chan- 
nels and streams (applied to the LAN interface 150) to 
appropriate output interfaces. 

A call signalling interface 156 receives a translated ver- 
sion of signalling messages received on the H.225 call 

55 signalling channel 14, i.e. the processor 152 and memory 
device 154 co-operate to translate incoming call signalling 
messages into an acceptable broadband format, such as 
DSS1/IDSS2, for onward routing (via the control signalling 
channel 114) to the call handler 116. The processor 152 also 

60 packages control messages (received on the negotiation 
control channel 26) and information (received on the audio, 
video and data streams 28-32) into a mini-channel format 
suitable for use in the broadband network. This mini-channel 
format is output through a broadband ATM/virtual channel 

65 interface 158 to the first virtual channel resource 134. 

As will now be appreciated, the memory device 154 acts 
as a storage medium for temporarily storing information 
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passing between the LAN and a broadband network, and 
also contains look-up tables associated with address and 
routing information, active call and connection information, 
and signalling protocol translation schemes used to translate 
LAN signalling to narrowband/broadband signalling. 

Operation of the architecture of the preferred embodiment 
of the present invention will now be described with particu- 
lar regard to FIG. 7. In response to receiving conventional 
LAN streams from the call signalling channel 14 (step 200 
of FIG. 7), the gateway interface 112 first converts call 
signalling information (received on the call signalling chan- 
nel 14) into an appropriate format, such as DSS1, and 
forwards this onward to the call handler 116. More 
particularly, as will now be understood, the call signalling 
information contains an address of a called party (normally 
as a telephone number, although an E-mail address can also 
be used) and an identity (e.g. a telephone number and/or 
E-mail address) of a requesting multimedia terminal. As 
such, it might be necessary to translate (at least) the address 
of the called party into a format acceptable to the broadband 
network (step 202). In other words, the gateway interface 
may need to generate a telephone number for use in the 
broadband network. 

This address mapping process can be executed within the 
call hander 116 or within the gateway interface 112, after 
which the communication system begins to establish a 
connection. As a consequence of this procedure, data 
received by the gateway interface 112 (by way of the audio, 
video and data streams 28-32 and the negotiation control 
channel 26) will typically need to be stored, temporarily, in 
memory 154. As will be appreciated, in a multimedia call, 
the LAN streams can be considered as forming distinct 
traffic components in the call. 

Using the telephone number of the called party, the call 
handler selects an outgoing route, i.e. the next exchange 118, 
and a trunk circuit leading to that next exchange (step 204). 
The connection supervisor 120 is then notified of the 
selected trunk circuit. Optionally, the call handler can send 
an SS7 LAM to the next exchange 118 (via the call signalling 
channel 115), but there is an associated risk because, at this 
time, there is no guarantee that a successful path can be set 
up across exchange 142. In the event that an IAM is sent, 
then the relevant next exchange 118 then responds to the call 
handler 116 and identifies/confirms the address identity or 
identities that, respectively, has or have been ear-marked for 
the call; this mechanism is therefore analogous to the prior 
art procedure described in relation to FIG. 1. The call 
handler 116 sends the identity of a selected trunk circuit to 
the connection supervisor 120 which in turn makes the 
connections across the virtual channel switch 128 and mini- 
channel switch 126 (as appropriate) to connect the H.245 
control channel on the first virtual channel resource 134 to 
the connection supervisor 120 and then onto the second 
virtual channel resource 140 (step 206). In this respect, the 
call handler is under the impression that it is setting up a 
whole trunk call whereas, in fact, the call handler 116 is only 
setting up the H.245 negotiation control channel. 

As a brief re-cap, the calling party dials the number of the 
called party and, in response thereto, the call handler 116 
analyses the called number and selects out-going route 
(based on the called number) to next exchange 118. 
Preferably, the call handler 116 selects a trunk circuit 
belonging to the out-going route, although this function may 
be performed by the connection supervisor 120. Rather than 
asking the virtual channel switch 128 to set-up media paths 
for the call, the call handler 116 then asks connection 
supervisor 120 to set-up the call. 


96,840 Bl 

10 

Step 206 is now described in more detail. The connection 
supervisor 120 interacts with the gateway interface 112, the 
virtual channel switch 128 and the mini-channel switch 126 
to orchestrate a broadband connection. A first step requires 

5 the selection of a first mini-channel of the first virtual 
channel resource 134, which mini-channel is incident to the 
gateway interface 112. Preferably, the connection supervisor 
120 makes the selection of the first mini-channel. A first 
connection is made (through use of control channels 

10 130-132) between the gateway interface 112 and the con- 
nection supervisor 120, which connection uses the first 
mini-channel and is made via the virtual channel switch 128 
and the mini-channel switch 126. The connection supervisor 
then uses the trunk circuit identity (received from the call 

15 handler 116) to select a virtual channel and a second 
mini-channel from the available virtual channels of the 
second virtual channel resource 140. A second connection is 
then made between the connection supervisor 120 and the 
other exchange 118 using the selected virtual channel and 

20 the second mini-channel via the virtual channel switch 128 
and the mini-channel switch 126. The connection supervisor 
120 associates the first mini-channel and the second mini- 
channel with each other and the H.323 call. 
At step 208, the call handler 116 sends a signalling 

25 message over the call signalling channel 115 to provide 
details of the set-up to the next exchange 118. In the 
preferred embodiment, the signalling message is an SS7 
IAM containing the selected trunk circuit identity, the virtual 
channel identity and the mini-channel identity; the latter two 

30 are within the user-to-user field. The call handler 116 should 
receive from the next exchange 118 a message confirming 
the trunk circuit identity, etc. However, if an IAM was sent 
during step 204 (and hence did not include the virtual 
channel identity and mini-channel identity), then the virtual 

35 channel identity and the mini-channel identity must now be 
sent within a SS7 user-to-user information message. 

The initial communication with the next exchange can 
actually be performed within step 204 or within step 208; the 
latter is a safer mechanism because the path has been 
established to the next exchange at this point. 

The connection supervisor 120 instructs the gateway 
interface 112 to launch any previously stored H.245 control 
messages (received on the negotiation control channel 26) to 

45 the first mini-channel that has just been set up. Specifically, 
the stored control messages are formatted into packets and 
cells as required by the mini-channels, and then placed on 
the ATM virtual channel 134 for transmission to the con- 
nection supervisor (step 210 of FIG. 7) and then onto the 

50 next exchange 118 via the second mini-channel. 
Furthermore, using H.245, the end points (in this case 
multimedia terminal 110 and subscriber terminal 119) 
exchange control messages via the connection supervisor 
120 to ascertain a common functional capability regarding 

55 audio, video and data. 

The call handler 116 is now under the impression that the 
call set-up has been completed. 

The next stage is to set up the required audio, video and/or 
data paths. Typically (but not necessarily), all mini-channels 

60 for the same H.323 call reside within a single virtual 
channel. In relation to each required path, the following 

In step 212, the calling unit that initiated the call set-up 
(i.e. the multimedia end point 110 in this example) now 
65 sends an H.245 control message to the exchange 142, which 
message is actually relayed to the connection supervisor 
120. The connection supervisor 120 assimilates the infor- 
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mation contained in the H.245 control message and sets up 
a path between the gateway interface 112 and the next 
exchange 118. To accomplish such a path, the connection 
supervisor 120 selects: i) a third mini-channel of the first 
virtual channel resource 134; and ii) a fourth mini-channel 
of the second virtual channel resource 140. The connection 
supervisor 120 then connects the third min-channel and the 
fourth mini-channel together via the virtual channel switch 
128 and the mini-channel switch 126. The connection super- 
visor 120 generates relevant H.245 control messages and 
sends them to the next exchange 118. Upon receipt of H.245 
control messages from the next exchange 118, the connec- 
tion supervisor 120 sends the corresponding H.245 control 
messages back to the gateway interface 112 for transmission 
back to the multimedia end-point 110. 

The process described above must be repeated for every 
audio, video or data path required. 

The gateway interface 112 now operates to encode any 
stored traffic (obtained from the audio, video and data 
streams) into mini-channels that are then communicated to 
the next exchange 118 and ultimately (in an appropriate 
form) to the subscriber terminal 119. As will be understood, 
the initiating end-point may start to transmit information 
before the exchange 142 (as a whole) is quite ready. 
Therefore, buffering is usually provided within the gateway 
interface 112. 

At step 214 of FIG. 7, audio, video and/or data transmis- 
sion can now occur over the assigned mini-channels set up 
for these purposes. In relation to the LAN streams, LAN 
traffic packets from the respective streams must be seg- 
mented (i.e. sized and labelled with a header) into mini- 
packets (e.g. AAL-2 packets). In the reverse direction, 
mini-packets are re-assembled to form LAN packets for the 
respective LAN streams (step 216). 

The set-up of the H.323 call is now complete. 

There are numerous ways of clearing down the H.323 
call. It is possible to have a partial clear-down in which 
audio, video or data paths are individually cleared down. To 
do this, an H245 control message is sent to the connection 
supervisor 120 that reacts by clearing down the relevant 
mini-channels. Alternatively, the whole call can be released 
by sending a release message over the call signalling chan- 
nel 114 or 115 to the call handler 116. The call handler is 
unable to clear down the call itself and must therefore solicit 
the assistance of the connection supervisor 120 to clear 
down all mini-channels related to the H.323 call. The 
mechanism is, however, dependent upon the direction from 
which clear down is initiated. Specifically, different signal- 
ling systems exist between: the call handler 116 and the 
gateway interface (e.g. DSS1 or DSS2); and the call handler 
116 and the next exchange 118 (e.g. signalling system no. 7 
(SS7)). 

In relation to the operation of the mini-channel switch 
126, the connection supervisor 120 is responsible for asso- 
ciating the input and output ports of the mini-channel switch 
126 and therefore accordingly notifies the mini-channel 
switch 126. 

To describe the invention is a different but complementary 
way, one can consider the following. Call signalling is used 
to set-up and clear-down an H.245 control channel applied 
to the gateway interface 112. On the LAN 10, call signalling 
is achieved using H.323 (H.225) call signalling messages; 
while DSS1/DSS2 signalling messages are utilised in the 
narrowband/broadband access network, and SS7 N-ISUP/ 
B-ISUP signalling messages are used for call signalling in 
the narrowband/broadband trunk network. On the LAN 10, 
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routing of the H.323 call can be based upon transport 
addresses, telephone numbers (as per E-164) or E-mail 
addresses, while the call handler 116 bases its routing upon 
telephone numbers. Also, on the LAN 10 and where 

5 appropriate, the relevant infrastructure and subscriber enti- 
ties know the transport address of each end of the H.245 
control channel, whereas a relevant call handler in the access 
network knows the access circuit identity for the H.323 call. 
In the trunk network, the relevant call handler knows the 

to trunk circuit identity used for the H.323 call. 

In other words, the call handler 116 has been hood-winked 
in the present invention into believing that the gateway 
interface 112 is a subscriber and hence operating within its 
access network. The call handler 116 believes that the next 

15 exchange 118 is connected to its trunk network (either 
narrowband or broadband). 

When the call handler 116 sets up an H.323 call, the call 
handler 116 believes that the whole call has been established 
while, in fact, only the H.245 control channel has been set 

20 up. In the system of the present invention, no call handler or 
call signalling message knows the identity of any audio, 
video or data channel. 
An outgoing call from the LAN 10 will be established on 

25 the following basis. The first significant event occurs when 
the call handler 116 receives a DSS1/DDS2 set-up message 
from the gateway interface 112. In response thereto, the call 
handler 116 performs digit analysis (of the called telephone 
number) and then selects an outgoing route (and hence a 

30 next exchange) while also selecting a trunk circuit within the 
outgoing route. The outgoing route must be selected before 
any inter-exchange virtual channel can be selected. The 
connection supervisor 120 obtains the outgoing trunk circuit 
identity from the call handler 116 and then selects and sets 

35 up associated virtual channels and mini-channels on which 
control messages will be sent and received. 

In relation to the bandwidth of an outgoing call, a bearer 
capability field in the H.323 call signalling set-up message, 
received from the LAN 10, indicates the required bandwidth 

40 for the call. This bandwidth indication is then used by the 
connection supervisor 120 to select a virtual channel of 
appropriate bandwidth between the gateway interface 112 
and the virtual channel switch 128. Usually, subsequent 
virtual channels used for the H.323 call will have the same 

45 bandwidth. 

For an incoming call, the call handler 116 receives, from 
an interconnected exchange 118, an SS7 N-ISUP/B-ISUP 
IAM message on the call signalling channel 115. This 
message contains a trunk circuit identity associated with an 

50 H.245 control mini-channel. The IAM message also 
includes, within its user-to-user field, an indication of which 
mini-channel in which incoming virtual channel (used to 
relay H.245 control messages) corresponds to the above 
mentioned trunk circuit identity; this indication is utilised by 

55 the connection supervisor 120 to identify the appropriate 
virtual channels and mini-channels. The call handler 116 
asks the connection supervisor 120 to set up a single 64 kbps 
circuit (in the narrowband case), i.e. the circuit required for 
use as the H.245 control channel. Note that, in a preferred 

60 embodiment, the connection supervisor is arranged to set up 
an appropriate virtual channel and mini-channel leading to 
the gateway interface 112, rather than a 64 kbps circuit. In 
relation to bandwidth allocation for an incoming call, the 
true required bandwidth will be obtained from the user-to- 

65 user field of the IAM message. The connection supervisor 
then uses this bandwidth to set-up the appropriate virtual 
channel. 
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In relation to point-to-multi-point communication (which 
is supported by H.323), the connection supervisor 120 is 
arranged to consolidate separate calls (that would otherwise 
be supported on separate and distinct virtual channels) 
through a conference bridge connected to the mini-channel 5 
switch 126. 

In summary, therefore, once the relevant end-point (or 
terminal) identities (e.g. telephone numbers, E-mail 
addresses, etc.) and address identities (e.g. trunk circuit 
identity and virtual channel plus mini-channel identities) 1Q 
have been exchanged between the gateway interface 112 and 
the exchange 118, a first AAL-2 mini-channel is used as a 
control (signalling) channel, and this first mini-channel then 
controls the setting up and clearing down of other AAL-2 
mini-channels which support the same H.323 multimedia JS 
call between the multimedia endpoint 110 (of the LAN 10) 
and the subscriber terminal 119. In other words, H.323 LAN 
streams are converted into AAL-2 mini-channels by the 
gateway interface 112, and then carried on a virtual channel 
which is itself controlled by an AAL-2 mini-channel using 2Q 
encoded H.245 control messages. 

Basically, the present invention uses control messages 
specific to a first type of network in a different context within 
an intermediate network (i.e. a broadband network) such as 
to set-up requisite media paths in the intermediate network, 2 s 
whereas the prior art uses a gateway at each boundary to the 
intermediate network to convert entirely all control mes- 
sages and media formats for transport across the intermedi- 
ate network. 

Rather than having the system of the present invention 30 
establish a trunk connection between the LAN and the called 
subscriber's exchange, the preferred embodiment of the 
present invention establishes AAL-2 mini-channels. 

In relation to the application of the set-up procedure of the 
preferred embodiment, this set-up procedure is equally 35 
applicable, for example, to situations where AAL-5 is used 
instead of AAL-2, or to where a mixture of AAL-1, AAL-5 
and AAL-2 are used instead of just AAL-2. It will be 
appreciated that the various ATM adaptation layers are 
geared towards optimal transport of different types of infor- 40 
mation and that, as such, AAL-2 is more efficient in relation 
to voice communication as compared with AAL-5 that is 
optimal for long data messages. Again, the call handler 116 
is under the impression that it has set-up a call between the 
gateway interface 112 and the next exchange 118, although 45 
in practice the call handler has, in fact, delegated the set-up 
to the connection supervisor which actually merely sets up 
the H.245 control channel. This H.245 control channel could 
be an AAL-5 virtual channel, an AAL-2 sub-channel within 
a virtual channel, or a functional equivalent. The H.245 50 
control channel is now used to set-up the actual paths for the 
audio, video or data communication. These actual audio, 
video or data paths can use either AAL-1, AAL-2 or AAL-5. 
In other respects, the call set-up procedure is unaltered at a 
functional level, although minor and readily appreciated 55 
changes will be required to the hardware within, for 
example, the gateway interface 112. 

The present invention therefore advantageously provides 
a mechanism for interconnecting a LAN to a broadband/ 
mini-channel network, while ostensibly maintaining con- 60 
ventional H.323 calls across the system. More particularly, 
the present invention provides an integrated architecture 
having increased functionality, with this accomplished with- 
out the need for significant changes in the signalling proto- 
cols of either system, other than in relation to address and 65 
port information that potentially needs to be transposed to 
provide inter-network addresses. 


We claim: 

1. A method of connecting a first network to a second 
network via an intermediate network, the first network and 
second network using a set of control messages to control 
media paths between the first network and the second 
network, the method comprising: 

using a call handler independent of a switch to establish 
a control channel across the intermediate network to 
carry the set of control messages; 

at a connection supervisor coupled to the switch and 
responsive to the call handler, intercepting the set of 
control messages in the intermediate network and 
determining a requirement for media paths, based on an 
interpretation of the types of intercepted control 
messages, in response thereto; 

in response to the determination, having the connection 
supervisor set up media paths in the intermediate 
network to connect paths to carry media traffic between 
the first network and the second network. 

2. The method of connecting according to claim 1, 
wherein the set of control messages are communicated on an 
end-to-end basis. 

3. The method of connecting according to claim 1, 
wherein intercepting the control messages further includes 
the step of identifying the type of communication required 
in the media paths. 

4. The method of connecting according to claim 3, 
wherein the intermediate network is a broadband network. 

5. The method of connecting according to claim 1, 
wherein the control channel and the media paths use AAL-5. 

6. The method of connecting according to claim 1, 
wherein the call handler is responsive to a calling party, the 
method further comprises the steps of: 

having the calling party dial a number of a called party; 

analysing the number of the called party in the call 
handler and selecting an out-going route to the second 
network based on the number of the called party; 

having the call handler instruct the connection supervisor 
to set-up control channel. 

7. The method of connecting according to claim 1, 
wherein the media paths carry at least one of audio traffic, 
video traffic and data traffic. 

8. The method of connecting according to claim 1, 
wherein the control messages are H.245 control messages. 

9. The method of connecting according to claim 1, 
wherein the media paths use of one AAL-1, AAL-2 and 
AAL-5. 

10. The method of connecting according to claim 6, 
further comprising having the connection supervisor indi- 
cate to the call handler that the control channel is set-up 
between a gateway interface and the second network. 

11. The method of connecting according to claim 10, 
wherein the control channel is a virtual path that used one of 
AAL-2 and AAL-5. 

12. A method of connecting a communication traffic 
comprised of a plurality of traffic components across a 
broadband network from a local area network, the method 


in the local area network, generating control messages for 
controlling the traffic components and applying those 
control messages to the broadband network; 

establishing a communication path within the broadband 
network to carry at least one of the plurality of traffic 
components, the communication path established using 
a call handler, independent of a switch, to establish a 
control channel across the broadband network to carry 
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the control messages and wherein a connection 
supervisor, coupled to the switch and responsive to the 
call handler, intercepts the control messages to deter- 
mine a requirement for media paths, based on an 
interpretation of the types of intercepted control 
messages, in response thereto, the connection supervi- 
sor setting up media paths in the broadband network to 
provide the communication path to carry media traffic 
across the broadband network from the local area 
network; and 

in the broadband network, using the control messages to 
control transfer of the plurality of traffic components 
over the communication path. 

13. The method of connecting according to claim 12, 
wherein the plurality of traffic components are from the set 
of video, audio and data traffic. 

14. The method of connecting according to claim 12, 
wherein the communication path is a virtual channel. 

15. The method of connecting according to claim 14, 
wherein the virtual channel comprises a plurality of mini- 
channels and wherein the control messages are enveloped 
within at least one mini-channel. 

16. The method of connecting communication traffic 
according to claim 12, further comprising: 

at the interface (112), receiving a local area network 
address and translating (202) said local area network 
address into a broadband network address. 

17. The method of connecting according to claim 12, 
further including: 

in relation to a point-to-multipoint call having a plurality 
of destination addresses, consolidating traffic compo- 
nents for each of the plurality of destination addresses 
into a mini-channel. 

18. A connection supervisor for orchestrating the com- 
munication of traffic components between first and second 
networks via an intermediate network, the connection super- 
visor responsive, in use, to control messages communicated 
between the first and second networks over a control channel 
established by a call handler, the connection supervisor 
including: 

means for intercepting and determining types of control 
messages sent across the control channel; and 

means for establishing media paths dependent upon the 
determination of types of control messages sent across 
the control channel, the media paths being arranged to 
transfer the traffic components across the intermediate 
network; 
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wherein said connection supervisor is, in use, responsive 
to the call handler, the call handler being independent 
of a switch in the intermediate network and the con- 
nection supervisor arranged, in use, to be coupled to the 
5 switch. 

19. The connection supervisor of claim 18, wherein the 
intermediate network is a broadband network and the com- 
munication path and the media paths are virtual channels. 

20. The connection supervisor of claim 18, wherein the 
media paths carry at least one of audio traffic, video traffic 
and data traffic. 

21. A communication node having a gateway that pro- 
vides an interface to a first end-point in a network, the first 

1S end-point arranged to initiate a call through the communi- 
cation node by sending to the gateway a called party number 
of a second end-point coupled to an exchange and wherein 
control messages are communicated between the first end- 
point and the second end-point, the communication node 
20 further comprising: 

a call handler coupled to the gateway and responsive to 
the called party number, the call handler arranged to 
select, in response to receipt of the called party number, 
a control channel that supports transfer of the control 
25 messages between the gateway and the exchange, the 
call handler independent of a switch; and 
a connection supervisor, coupled to the call handler and 
connectable to the switch, the connection supervisor 
30 operationally responsive to the call handler, the con- 
nection supervisor having: 

(i) means for determining types of control message sent 
across the control channel; and 

(ii) means for establishing media paths between the 
35 gateway and the exchange dependent upon the deter- 
mination of types of control message sent across the 
control channel, the media paths being arranged to 
transfer traffic components across the communica- 

40 22. The communication node of claim 21, wherein the 
communication node is a broadband network and wherein 
the control channel and the media paths are virtual channels. 

23. The communication node of claim 21, wherein the 
control messages are H.245 control messages. 

45 24. The communication node of claim 21, wherein the 
media paths use of one AAL-1, AAL-2 and AAL-5. 
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ABSTRACT 


A method and an apparatus for interworking between inter- 
net protocol (IP) telephony protocols includes a call server. 
The call server includes a first protocol agent for commu- 
nicating with a first protocol device according to a first 
protocol. A second protocol agent communicates with a 
second protocol device according to a second protocol. An 
interworking agent provides functions usable by the first and 
second protocol agents to communicate with each other 
according to a third protocol. The third protocol is a superset 
of functions provided by the first and second protocols. 
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METHOD AND APPARATUS FOR 
INTERWORKING BETWEEN INTERNET 
PROTOCOL (IP) TELEPHONY PROTOCOLS 

PRIORITY APPLICATION 

This Application claims the benefit of U.S. Provisional 
Patent Application Ser. No. 60/137,867 filed Jun. 7, 1999, 
the disclosure of which is incorporated herein by reference 
in its entirety. 

TECHNICAL FIELD 

The present invention relates to a method and an appa- 
ratus for interworking between communications protocols. 
More particularly, the present invention relates to a method 
and an apparatus for interworking between internet protocol 
(IP) telephony protocols. 

BACKGROUND ART 

There are a variety of known protocols for establishing 
media stream communications, such as voice, data, video, or 
combinations thereof, over an IP network. Protocols for 
establishing media stream communications over an IP net- 
work are referred to herein as IP telephony protocols. One 
example of an IP telephony protocol is the media gateway 
control protocol (MGCP). MGCP defines signals and events 
by which a software entity, known as a media gateway 
(MG), is controlled by another software entity, known as a 
media gateway controller (MGC), in a packet network. The 
media gateway controller processes call control signaling 
from one or more signaling gateways (SGs) and utilizes 
MGCP media control signaling to establish media streams 
between MGs. An MGC that processes call control signaling 
in this manner is also referred to as a call agent. The terms 
media gateway controller and call agent are used inter- 
changeably herein. The media gateway controller performs 
call control functions, such as translations, resource 
management, media capabilities negotiation and selection, 
and media stream management. It can also provide addi- 
tional services. 

FIG. 1 illustrates conventional communications using 
MGCP. In FIG. 1, MGC 100 receives call signaling infor- 
mation from SGs 102 and 103 and controls MGs 104 and 
105 to establish packetized media stream communications 
between end users in packet network 106. For example, SG 
102 and MG 104 can be associated with a calling party end 
user device for a given media stream communication. 
Similarly, SG 103 and MG 105 can be associated with a 
called party end user device for a given media stream 
communication. MGC 100 can control MGs 104 and 105 to 
establish media stream communications between the called 
and calling end user devices, such as PSTN terminals. 

A detailed explanation of MGCP is found in Media 
Gateway Control Protocol (MGCP), Version 0.1 Draft, Inter- 
net Engineering Task Force, Feb. 21, 1999, the disclosure of 
which is incorporated herein by reference in its entirety. 

Another example of an IP telephony protocol is Interna- 
tional Telecommunications Union (ITU) Recommendation 
H.323. H.323 defines a protocol by which endpoints, such as 
gateways, terminals, or multipoint control units MCUs), can 
place calls in a packet network. A gateway translates 
between circuit-switched and packet-switched communica- 
tion protocols. A terminal is a device, such as an IP terminal, 
that provides end user access to a network. An MCU is a 
device that supports conferences between three or more 
endpoints. H.323 defines a gatekeeper as an entity that 
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provides address translation and controls access to the 
packet network for H.323 endpoints. The gatekeeper can 
also provide additional services, such as call control and 
supplementary services. 

5 FIG. 2 illustrates an example of conventional H.323 
communications. In FIG. 2, a first gateway 200 can be 
associated with a calling end user device and a second 
gateway 202 can be associated with a called end user device 
for a given media communication. Gatekeeper 204 performs 

io call signaling functions, such as call setup and teardown, to 
establish calls between end user devices associated with 
gateways 200 and 202. The end user devices can be PTSN 
terminals connected to gateway 200. Alternatively, gateway 
200 can be omitted and replaced by H.323 terminals or 

15 H.323 MCUs. Once gatekeeper 204 performs the call sig- 
naling functions necessary to set up a call, the media stream 
for the call flows between gateways 200 and 202. Detailed 
information relating to H.323 can be found in ITU Recom- 
mendation H.323, Packet Based Multimedia Communica- 

20 tions Systems, February 1998, the disclosure of which is 
incorporated herein by reference in its entirety. 

Yet another IP telephony protocol is ITU Recommenda- 
tion H.248. The Internet Engineering Task Force (IETF) 
formed the MEGACO Group to evolve the MGCP protocol. 

25 As the MEGACO Group matured the protocol, the 
MEGACO Group allied itself with the ITU, and the speci- 
fication developed by the MEGACO Group has become 
known as ITU Recommendation H.248. Thus, ITU recom- 
mendation H.248 can be viewed similarly to MGCP. 

30 Another IP telephony protocol is the session initiation 
protocol (SIP). SIP is an application layer signaling protocol 
for creating, modifying, and terminating sessions between 
one or more participants. The sessions include internet 
multimedia conferences, internet telephone calls, and mul- 
timedia distribution. SIP originated from Columbia Univer- 
sity and is gaining acceptance as a protocol for exchanging 
call signaling information over a packet network. A detailed 
description of SIP can be found in Request for Comments 

4Q (RFC) 2543 SIP: Session Initiation Protocol, March 1999, 
the disclosure of which is incorporated herein by reference 
in its entirety. 

In addition to the published protocols described above, 
many vendors of telecommunications equipment and ser- 

4J vices are supporting IP telephony applications via propri- 
etary protocols. 

All of the IP telephony protocols described above are 
being implemented by various vendors. However, standards 
for interworking equipment that communicates using one 

5 0 protocol with equipment that communicates using another 
protocol are immature, nonexistent, or focus only on a 
specific type of application. Accordingly, there exists a 
long-felt need for a novel method and apparatus for inter- 
working between IP telephony protocols. 

55 DISCLOSURE OF THE INVENTION 

The present invention provides a novel method and appa- 
ratus for interworking between IP telephony protocols. 
Although most of the examples described below relate to 

60 MGCP and H.323, it is understood that the method and 
apparatus described herein are applicable to any IP tele- 
phony protocol. 

Many of the protocols described herein define an entity 
that is responsible for performing functions and requests on 

65 behalf of a telephony device. Typically, these functions and 
requests include translations, media capabilities exchange, 
and other services. The entities that perform the functions 
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can be logical, physical, or both. For example, in MGCP, the 
MGC or call agent performs call signaling functions on 
behalf of a gateway. In H.323, the gatekeeper performs call 
signaling functions for an H.323 gateway. In SIP, a proxy 
server performs call signaling functions for an end user. In 
order to facilitate a description of the present invention, the 
term call server is used herein to refer to an entity that 
performs call signaling functions, such as translations and 
media capabilities exchange, on behalf of an end user 
device, gateway, or other entity. 

According to a first aspect, the present invention includes 
a call server including a first protocol agent and a second 
protocol agent. The first protocol agent communicates with 
a first protocol device according to a first protocol. The 
second protocol agent communicates with a second protocol 
device according to a second protocol. An interworking 
agent provides functions usable by the first and second 
protocol agents to communicate using a third protocol. The 
third protocol provides a superset of the functions provided 
by the first and second protocols. 

Accordingly, it is an object of the present invention to 
provide a novel method and apparatus for interworking 
between IP telephony protocols. 

An object of the invention having been stated 
hereinabove, and which is achieved in whole or in part by 
the present invention, other objects will be evident as the 
description proceeds, when taken in connection with the 
accompanying drawings as best described hereinbelow. 
BRIEF DESCRIPTION OF THE DRAWINGS 

A description of the present invention will now proceed 
with reference to the accompanying drawing of which: 

FIG. 1 is a block diagram illustrating conventional MGCP 
network entities; 

FIG. 2 is a block diagram illustrating conventional H.323 
network entities; 

FIG. 3 is a block diagram illustrating media gateway 
controller and gatekeeper functions implemented within a 
call server according to an embodiment of the present 
invention; 

FIG. 4 is a block diagram illustrating a call server wherein 
each call half is represented by an agent according to an 
embodiment of the present invention; 

FIG. 5 is a block diagram illustrating a call server 
including a plurality of interworking agents according to an 
embodiment of the present invention; 

FIG. 6 is a block diagram illustrating protocol agents 
implementing originating and terminating call half functions 
executing on different machines wherein an interworking 
agent is associated with each protocol agent; 

FIG. 7 is a block diagram illustrating a call server 
including MGCP, interworking, and H.323 agents for inter- 
working MGCP and H.323 entities according to an embodi- 
ment of the present invention; 

FIG. 8 is a block diagram illustrating a connection infor- 
mation parameter data structure according to an embodiment 
of the present invention; 

FIGS. 9(a) and 9(b) are flow charts illustrating message 
tunneling according to an embodiment of the present inven- 

FIG. 10 is a block diagram illustrating exemplary agent 
interworking protocol message structures according to an 
embodiment of the present invention; 

FIG. 11 is a block diagram illustrating an exemplary data 
structure for a digit information parameter according to an 
embodiment of the present ' 


FIG. 12 is a call flow diagram illustrating exemplary call 
signaling for H.323 fast start to MGCP communications 
according to an embodiment of the present invention; 

FIG. 13 is a call flow diagram illustrating H.323 non-fast- 
5 start to MGCP communications according to an embodiment 
of the present invention; 

FIG. 14 is a call flow diagram illustrating exemplary call 
signaling for a hold scenario between H.323 and North 
American Q.931 endpoints according to an embodiment of 
10 the present invention; 

FIG. 15 is a call flow diagram illustrating exemplary call 
signaling for a retrieve scenario between H.323 and North 
American Q.931 endpoints according to an embodiment of 
the present invention; 

FIG. 16 is a call flow diagram illustrating exemplary call 
ignaling for a hold scenario between H.323 and MGCP 
endpoints according to an embodiment of the present inven- 

FIG. 17 is a call flow diagram illustrating exemplary call 
ignaling for a retrieve scenario between H.323 and MGCP 
endpoints according to an embodiment of the present inven- 

FIG. 18 is a call flow diagram illustrating exemplary call 
; signaling between H.323 and MGCP endpoints for common 
channel signaling according to an embodiment of the present 


FIG. 19 is a call flow diagram illustrating exemplary call 
signaling between an MGCP gateway and an H.323 gateway 
30 according to an embodiment of the present invention. 


The present invention provides a novel method and appa- 

3S ratus for interworking between IP telephony protocols. In 
order to provide this interworking, a call server includes 
agents that communicate with other entities according to the 
protocols implemented by the other entities. However, the 
protocol agents communicate with each other utilizing a 

40 protocol-independent agent interworking protocol (AIP). As 
a result, network entities that implement different protocols 
can seamlessly communicate with each other. 

FIG. 3 illustrates a call server including MGC and GK 
functions according to an embodiment of the present inven- 

45 tion. In FIG. 3, a call server 300 includes an MGC function 
302 and a GK function 303. The call server is a software 
entity that can execute on a single machine or on multiple 
machines. MGs and SGs recognize call server 300 as an 
MGC. H.323 endpoints, such as gateways, recognize call 

50 server 300 as a GK. For example, in the illustrated 
embodiment, ingress MG 304, egress MG 306, and SG 308 
recognize call server 300 as an MGC. Similarly, ingress 
H.323 gateway 310 and egress H.323 gateway 312 recog- 
nize call server 300 as a gatekeeper. 

55 In order for MGs 304 and 306 to recognize call server 300 
as an MGC, MGC function 302 in call server 300 is adapted 
to communicate with MGs 304 and 306 using MGCP. 
Similarly, in order for SG 308 to recognize call server 300 
as an MGC, MGC function 302 in call server 300 commu- 

60 nicates with SG 308 using a call signaling protocol, such as 
ISDN Part (ISUP). In order for H.323 gateways 310 and 312 
to recognize call server 300 as a gatekeeper, gatekeeper 
function 303 in call server 300 communicates with gateways 
310 and 312 according to ITU Recommendations H.225 and 

65 H.245. 

FIG. 4 illustrates an embodiment of call server 300 in 
which the call processing functions illustrated in FIG. 3 are 


8/10/05 EPR1.1 23-33 


US 6,885,658 Bl 


5 

separated into call agents, each of which performs call half 
functions. As used herein, call half functions refer to func- 
tions associated with either the originating or terminating 
side of a call. For example, in FIG. 4, MGCP function 302 
illustrated in FIG. 3 is divided into MGCP agent 302A and 
MGCP agent 302B. Similarly, H.323 function 303 illustrated 
in FIG. 3 is divided into H.323 agent 303A and H.323 agent 
303B. MGCP agent 302A and H.323 agent 303A can per- 
form call originating functions, such as collection of digits 
and translations. MGCP agent 302B and H.323 agent 303B 
can perform call terminating functions, such as trunk selec- 
tion and alerting the called party of an incoming call. The 
functions performed by each call half will be explained in 
detail below with reference to call flow diagrams. 

As mentioned above, the present invention is not limited 
to interworking between MGCP and H.323 entities. For 
example, FIG. 5 illustrates a call server including protocol 
agents configured to communicate with other agents using a 
variety of different protocols. In the illustrated embodiment, 
call server 300 includes MGCP agents 302A and 302B for 
processing MGCP to MGCP calls, H.323 agents 303A and 
303B for processing H.323 to H323 calls, H.323 agent 500A 
and MGCP agent 500B for processing H.323 to MGCP calls, 
H.323 agent 502A and SIP agent 502B for processing H.323 
to SIP calls, and H.323 agent 504A and NAQ.931 agents 
504B for processing H.323 to NAQ.931 calls. In addition, to 
the protocol agents, call server 300 also includes an inter- 
working agent 506 which facilitates communication 
between protocol agents. More particularly, interworking 
agent 506 includes methods for getting and setting AIP 
parameters, building AIP messages, and establishing and 
maintaining connections, such as TCP or reliable UDP 
connections, between protocol agents. Interworking agents 
can also identify AIP message types, which will be described 
in more detail below. Thus, as illustrated in FIG. 5, inter- 
working agent 506 provides functions usable by a variety of 
different protocol agents to provide seamless interworking 
between the protocol agents. 

In a preferred embodiment of the invention, the inter- 
working agent is divided into separate software components, 
one component associated with the protocol agent for each 
call half. The division of the interworking agent into two 
software components allows protocol agents associated with 
a given call to execute on separate machines. 

Referring to FIG. 6, call server 300 illustrated in FIG. 5 
is divided into call servers 300A, 300B, and 300C, which 
can execute on the same machine or on different machines. 
Call server 300A includes protocol agents that perform both 
originating and terminating call half functions. Call servers 
300B and 300C each include protocol agents that perform 
only originating or terminating call half functions. This 
division of call processing functionality is enabled by inter- 
working agents components 506A and 506B, which enable 
protocol agents to communicate with each other using AIP 
messaging. Exemplary information that can be exchanged 
using AIP messaging includes information regarding call 
progress, media capabilities and addresses, supplementary 
services, etc. By allowing the protocol agents to reside on 
separate machines, the interworking agents according to 
embodiments of the present invention allow efficient divi- 
sion of call processing functions. 

FIG. 7 illustrates an example of an MGCP-H.323 network 
typology wherein communication between MGCP and 
H.323 endpoints occurs through a call server according to an 
embodiment of the present invention. In FIG. 7, call server 
300 includes MGCP agent 700A for performing originating 
call half functions according to the media gateway control 
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protocol and H.323 agent 700B for performing terminating 
call half functions according to the H.323 protocol. More 
particularly, MGCP agent 700A communicates with ingress 
media gateway 304 according to the media gateway control 

5 protocol and with signaling gateway 306 according to a call 
signaling protocol, such as ISUP. H.323 agent 700B com- 
municates with H.323 gateway 312 according to H.225 and 
H.245 protocols. MGCP agent 700Aand H.323 agent 700B 
communicate with each other using AIP messaging. Inter- 

1Q working agent components 702 and 702B provide the func- 
tions that protocol agents 700A and 700B use to formulate 
and process AIP messages. 

Because the interworking agent components 702A and 
702B provide functions for converting messages to and from 
a protocol independent format, MGCP agent 700A and the 

15 H.323 agent 700B need not be aware of each other's 
protocol. Similarly, MG 304 and SG 306 need not be aware 
of the protocol of H.323 gateway 312, and H.323 gateway 
312 need not be aware of the protocol of MG 304 and SG 
306. 

20 Agent Interworking Protocol 

As stated above, interworking agents according to 
embodiments of the present invention communicate with 
each other according to a protocol independent format 

2S referred to as the agent interworking protocol. The agent 
interworking protocol is preferably capable of representing 
a reasonable superset of the messaging capabilities of all 
protocols to be supported within the packet network. 
Designing an interworking protocol that supports all of the 
capabilities of all of the supported protocols is an unneces- 

30 sarily burdensome task since some capabilities are rarely 
used or are only useful when communicating between 
devices that support the particular protocol. In addition, 
these rarely used capabilities can be communicated between 
agents that support these capabilities using tunneling, as will 

35 be described in more detail below. Accordingly, it is desir- 
able that the agent interworking protocol provide a reason- 
able superset of the capabilities of supported protocols. 

Rather than designing an entirely new protocol for use as 
the agent interworking protocol, it is more desirable to select 

40 an existing protocol that comes close to meeting the superset 
definition described above and extending that protocol. 
Existing protocols that could be used as the base protocol for 
the agent interworking protocol include Q.931, ISUP, and 
SIP. The agent interworking protocol implemented in inter- 

45 working agents according to preferred embodiments of the 
present invention is based upon ISUP. For example, AIP 
includes traditional ISUP messages such as initial address 
messages (IAM), answer messages (ANM), and release 
messages (REL). The agent interworking protocol extends 

so the base protocol to include additional procedures and 
signaling required to meet interoperability requirements. 
The functions and data structures used in the agent inter- 
working protocol to meet these requirements will now be 
discussed in more detail. 

55 One function that must be provided by the agent inter- 
working protocol is a method for exchanging media capa- 
bilities between protocol agents. Each of the agent protocols 
to be interworked provide some means by which a telephony 
device can make known the media capabilities that it sup- 

60 ports. These capabilities must be exchanged between two 
devices that desire to participate in a media stream commu- 
nication in order to select a mutually compatible media 
session definition. 

65 Capabilities Exchange Between H.323 Devices 

H.323 allows an endpoint to advertise its capabilities at 
two different times — during call establishment and after call 
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establishment. For example, some H.323 devices support 
fast start capabilities which allow a partial list of media 
capabilities to be exchanged in H.225 call establishment 
messages. This method of exchanging capabilities allows 
faster establishment of a media stream between endpoints 
because capabilities are exchanged during call signaling, 
rather than waiting until after call signaling has been com- 
pleted. In order to exchange capabilities after call 
establishment, H.323 compliant devices use H.245 signaling 
to provide a full description of all media capabilities sup- 
Capabilities Exchange Between MGCP and SIP 
Devices 

MGCP and SIP support the use of the session description 
protocol (SDP) for encoding the capabilities supported by 
the device. The session description protocol is included in 
call establishment messages similarly to H.323 fast start 
messages. For example, a SIP call establishment message, 
such as an INVITE message, includes an SDP portion in the 
body of the message. The SDP portion includes the capa- 
bilities supported by the endpoint, such as encoding and 
decoding algorithms, type of media stream, etc. 

Because these capabilities can be exchanged during call 
setup or after call establishment, the agent interworking 
protocol implemented in call servers according to embodi- 
ments of the present invention is preferably flexible enough 
to support capabilities exchange at either time. In addition, 
because each of the above-mentioned protocols uses differ- 
ent syntax for specifying the capability's definition, AIP 
preferably provides a normalized syntax to which interwork- 
ing agents can map the capability's definitions. 

Media Management 

In addition to providing a method for exchanging media 
capabilities, the agent interworking protocol preferably also 
provides media management capabilities that include a 
reasonable superset of the media management capabilities of 
supported protocols. For example, each of the agent proto- 
cols provide support for establishing and altering media 
streams; however, the specific protocols vary significantly. 
H.323 fast start procedures allow H.323 devices to establish 
a media stream in concert with call establishment. However, 
fast start is optional and might not be supported by a given 
H.323 device. H.245 procedures allow H.323 devices to 
open and close media channels post call establishment. 
H.323 is very limited in its ability to alter a media stream 
once established. H.323 media streams can be unidirectional 
or bi-directional. Voice/audio media is typically represented 
via two independent unidirectional streams on IP networks 
with bi-directional media being typically used for data or for 
voice on ATM networks. 

MGCP supports establishment of media streams during 
call establishment similar to H.323 fast start procedures. 
Media streams can be either unidirectional or bi-directional 
and can be changed from one format to the other at any time 
during a call. MGCP allows media channels to be modified 
in a variety of ways without having to be closed. For 
example, a media stream can be redirected by changing the 
receiving real time protocol (RTP) address. The encoding 
format can be changed by changing the codec. The mode can 
be changed to send only, send receive, receive only, or 
inactive. SIP is similar to MGCP in its ability to modify 
media streams. 

In order to provide an interworking solution that accom- 
modates these agent protocols, three design objectives are 
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preferably met. The first design objective is that the agent 
interworking protocols must provide sufficient flexibility to 
meet the requirements of all agent protocols. Second, the 
agent design preferably maps between agent specific and 

5 AIP procedures and syntax for media management. The 
third objective is that a flexible control framework is pref- 
erably implemented that allows the agent to easily react to 
media changes made by the agent implementing the other 
call half. The connection information parameter illustrated 

1Q in FIG. 8 is the mechanism provided by the agent inter- 
working protocol for implementing media management 
functions and exchanging media capabilities. The times for 
exchanging media capabilities and performing media man- 
agement functions according to the agent interworking pro- 
tocol will be described in more detail below with respect to 

15 the call flow diagrams. 

FIG. 8 is a table illustrating exemplary fields and field 
values for the connection information parameter according 
to an embodiment of the present invention. In FIG. 8, the left 
hand column represents the fields in the connection infor- 

20 mation parameter data structure. The right hand column 
represents example values for each of the fields in the left 
hand column. In the illustrated embodiment, the connection 
information parameter includes a media type field 800 that 
holds a media type value 802 for specifying the type of 

25 media being exchanged or sought to be exchanged in a 
media stream. Example values for the media type field 
include audio, video, and data. Channel ID field 804 
includes an internally assigned channel ID value that allows 
an interworking agent to identify the media stream. In the 

30 illustrated embodiment, 12345 is given as an example value 
806 for channel ID field 804. Channel operation field 808 
includes a channel operation value 810 for specifying the 
operation being performed on the media stream. Values 810 
for the channel operation field 808 are preferably a superset 

35 of protocol media stream operations for the supported pro- 
tocols. In the illustrated embodiment, exemplary values for 
the channel operation field are no action, open, close, 
modify, mode change, redirect, direct, and send capabilities. 
The no action value indicates that no change is being made 

40 to the existing media stream. The open value specifies that 
a media stream is sought to be opened. The close value 
indicates that an open media stream is sought to be closed. 
The modify value indicates that the media stream is sought 
to be modified, e.g., changing a codec from G.711 to G.729a. 

45 The mode change value indicates that the mode of the media 
stream is sought to be changed, e.g., from send only to 
receive only. The redirect value indicates that the media 
stream is to be redirected to another endpoint. The direct 
value specifies the location to which the media stream is to 

50 be directed. The send capabilities value requests the receiv- 
ing entity to transfer the media capabilities list. 

Current media description field 812 stores current media 
description value 814 for indicating the description of the 
current media stream. In the illustrated embodiment, an 

55 example of a current media description value is G.711 at two 
frames per packet. Media capabilities field 816 includes 
media capabilities value or values 818 that allows an entity 
to exchange its media capabilities with another entity. In the 
illustrated example, the media capabilities field includes a 

60 list of supported formats, such as G.711, G.729. Media 
capabilities field 818 also includes a payload size value that 
specifies the size of media capabilities field. Media capa- 
bilities field 818 also includes a redefinable area in which 
information specific to the type of media and codes can be 

65 specified. For example, a facsimile media stream requires 
certain attributes that are not required for other media types. 
The redefinable area allows this information to be specified. 
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Message Tunneling 


As described above, the agent interworking protocol 
represents a reasonable superset of the agent protocols 
sufficient to achieve interworking. However, the agent inter- 
working protocol is not a complete superset of the supported 
protocols. Thai is, certain agent protocols can contain mes- 
sages or parameters which do not map to any other agent 
protocols, but provide added value for a call between two 
devices of the same type. In this case, the agent interworking 
protocol preferably supports tunneling of the native protocol 
message. As used herein, tunneling refers to transferring the 
native protocol message from one protocol agent to another 
protocol agent without converting to and from the agent 
interworking protocol. The agent receiving the native pro- 
tocol message can inspect the message, and if the agent 
understands the message, process the message accordingly. 

An example of when it might be desirable to tunnel a 
message relates to H.323. H.323 provides a sophisticated 
means of representing terminal capabilities in sets. The 2Q 
agent interworking protocol, as described herein, might not 
include functionality for representing terminal capabilities 
in sets as defined in H.323, because the other protocols do 
not support such capability. Another capability that H.323 
supports which can not be supported by other protocols is 25 
the exchange of H.245 indications between two H.323 
devices. Some of these indications have no equivalent 
mapping to other agent protocols. In these situations, it can 
be desirable to tunnel the H.323 messages from one agent to 
another agent. 30 

Method of Tunneling Messages 
According to an embodiment of the present invention, 
interworking messages can be of three types: 

Agent Interworking protocol messages — protocol-neutral 35 

messages understood by all protocol agents; 
Native protocol messages — protocol-specific messages, 

such as SIP, MGCP, and H.323 messages; 
Multipart messages — messages that contain multiple 
other messages, such as native protocol messages and 40 
AIP messages. All agents are preferably capable of 
extracting the AIP message and processing the message 
accordingly. If the multipart message contains a native 
protocol message, this message is preferably processed 
if supported. 45 
FIGS. 9(a) and 9(b) are flow charts illustrating exemplary 
formulating and processing of interworking messages by a 
call server according to an embodiment of the present 
invention. The flow chart in FIG. 9(a) illustrates exemplary 
steps that can be performed by a sending protocol agent in 50 
formulating an interworking message using procedures pro- 
vided by an associated interworking agent. The flow chart in 
FIG. 9(b) illustrates exemplary steps that can be performed 
by a receiving protocol agent using procedures provided by 
an associated interworking agent upon receiving an inter- 55 
working message. Referring to FIG. 9(a), in step ST1, the 
sending protocol agent receives a message from an external 
entity, such as an H.323 gateway. In step ST2, the sending 
protocol agent determines whether a mapping is available to 
the agent interworking protocol. In step ST3, if a mapping 60 
is available, the sending protocol agent formulates the 
corresponding AIP message using functions provided by the 
interworking agent associated with the sending protocol 
agent (hereinafter, "the first interworking agent") and trans- 
mits the message to the receiving protocol agent (step ST4). 65 
In step ST2, if the sending protocol agent determines that the 
mapping to the agent interworking protocol is not available, 


the sending protocol agent simply transmits the protocol 
message without modification to the receiving protocol 
agent (step ST4). In step ST2, if the sending protocol agent 
determines that a mapping to AIP is partially available, the 
sending protocol agent can formulate a multiprotocol mes- 
sage including the AIP message and the native protocol 
message (step ST5). The sending protocol agent can then 
transmit the multiprotocol message to the receiving protocol 
agent (step ST4). 

Referring to FIG. 9(b), in step ST6, the receiving protocol 
agent receives the message from the sending protocol agent. 
In step ST7, receiving protocol agent determines the mes- 
sage type, i.e., whether the message is a protocol specific 
message, an agent interworking protocol message, or a 
multipart message, using procedures provided by its asso- 
ciated interworking agent (hereinafter, "the second inter- 
working agent"). 

In step ST8, if the receiving protocol agent determines 
that the message is an agent interworking protocol message, 
the receiving protocol agent processes the message (step 
ST9). In step ST10, the receiving protocol agent determines 
whether the message is a multipart message. If the message 
is a multipart message, the receiving protocol agent sepa- 
rates the multi-protocol message into its component mes- 
sages (step ST11). After the receiving protocol agent sepa- 
rates the message, the receiving protocol agent reads the 
protocol specific portion of the AIP message (step SH2). In 
step ST13, the receiving protocol agent determines whether 
the protocol in the protocol specific portion is supported. If 
the protocol is not supported, the receiving protocol agent 
discards the message (step ST14). If the protocol is 
supported, the receiving protocol agent processes the mes- 
sage (step ST15). In step ST16, the receiving protocol agent 
processes the AIP portion of the message. 

Referring to step ST17, if the receiving protocol agent 
determines that the message is a protocol specific message, 
the receiving protocol agent determines whether the protocol 
of the message is supported (step ST18). If the protocol is 
supported, the receiving protocol agent processes the mes- 
sage (step ST19). If the protocol is not supported, the 
receiving protocol agent discards the message (step ST20). 
Transport Mechanism for Agent Interworking 
Messages 

Interworking messages can be sent between protocol 
agents using any packet based protocol, for example, TCP, 
UDP, etc. In a preferred embodiment of the invention, 
interworking messages are transmitted between interwork- 
ing agents using TCP over IP. As is known in the art, an IP 
message includes a header portion and a data portion. A TCP 
message is encapsulated in the data portion of the IP 
message. The TCP message also includes a header portion 
and a data portion. Interworking messages are encapsulated 
in the data portion of the TCP message. Interworking 
messages also include a header portion and a data portion. 
The header portion indicates the message type, i.e., AIP, 
protocol-specific, or multipart. 

FIG. 10 illustrates the relationships between IP messages, 
TCP messages, and interworking messages. In FIG. 10, IP 
message 1000 includes a header portion 1002 and a data 
portion 1004. TCP message 1006 is encapsulated in data 
portion 1004 of IP message 1000. TCP message 1006 
includes a header portion 1008 and a data portion 1010. 

Interworking message 1012 is encapsulated in data por- 
tion 1010 of TCP message 1006. Interworking message 
1012 includes a header portion 1014 for indicating the 
message type and a data portion 1016 containing the actual 
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message. If the header portion 1014 indicates that the 
interworking message is a multipart message, data portion 
1016 of interworking message 1012 includes a first field 
1018 indicating the number of messages present in the 
multipart message. After the first field, the multipart mes- 
sage can include one or more interworking messages 1012A 
to 1012N. 

DTMF Digit Handling 

Another extension of the base protocol provided by the 
agent interworking protocol is dual tone multifrequency 
(DTMF) digit handling. Numerous studies have concluded 
that encoding and transporting DTMF digits within the 
media stream is not suitable for supporting networked 
services, such as credit card validation, automated services, 
and voice mail, which require DTMF digit recognition. 
Some of these services require recognition not only of the 
tone being transmitted but also of the duration of the tone. 
Algorithms for encoding voice and data can distort the tone 
and/or change the duration of the tone sought to be trans- 
mitted. As a result, the receiving application might not be 
able to correctly interpret the tone. 

Currently, a fully standardized approach for handling the 
transport of DTMF digits after call establishment is not 
defined. The approach that is currently in the most favor is 
to encode DTMF digits as a special real time protocol (RTP) 
payload type that is exchanged between devices participat- 
ing in the media stream. If this approach is standardized, 
various digital signal processor (DSP) manufacturers must 
comply with the standard before interworking will be 
accomplished. Because this involves a hardware change, 
much time can elapse before this occurs. 

As a current solution to the problem, some of the agent 
protocols have implemented out-of-band techniques for han- 
dling DTMF digits. The agent interworking protocol accord- 
ing to embodiments of the present invention preferably 
provides a mapping to and from the out-of-band DTMF digit 
handling techniques of supported protocols. In order to 
provide a method for communicating DTMF information 
between protocol agents, the agent interworking protocol 
defines a data structure referred to herein as the digit 
information parameter. FIG. 11 illustrates an exemplary digit 
information parameter data structure. In the illustrated 
embodiment, the digit information parameter data structure 
includes a digit field 1100 and a duration field 1102. Digit 
field 1100 is capable of storing a digit value indicative of the 
DTMF digit being transmitted. For example, the digit field 
can contain a numerical value that indicates one of the keys 
on a telephone handset. Duration field 1102 stores a duration 
value for indicating the duration of the tone represented by 
the digit in the digit field. Specific examples of when the 
digit information parameter is exchanged will be explained 
below with reference to the call flow diagrams. 

Interworking Examples 
A. H.323 Fast Start to MGCP 
FIG. 12 is a call flow diagram illustrating exemplary call 
signaling performed by H.323 and MGCP agents including 
interworking agent capabilities according to an embodiment 
of the present invention. In FIG. 12, H.323 endpoint 1200 is 
seeking to establish a call with an MGCP endpoint through 
MGCP gateway 1202. MGCP gateway 1202 performs both 
signaling gateway and media gateway functions. H.323 
agent 1204 includes interworking agent functionality and 
implements an originating call model. MGCP agent 1206 
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includes interworking agent functionality and implements a 
terminating call model. 

In line 1 of the call flow diagram, H.323 endpoint 1200 
sends a SETUP message to H.323 agent 1204. The SETUP 
5 message includes fast start parameters that specify suggested 
media options for the initial media stream. In line 2 of the 
call flow diagram H.323 agent 1204 sends an agent inter- 
working protocol initial address message (IAM) to MGCP 
agent 1206. 

10 The AIP IAM message contains the media capabilities 
definition mapped from the fast start parameters extracted 
from the SETUP message. In line 3 of the call flow diagram, 
MGCP agent 1206 sends an MGCP create connection 
(CRCX) message to MGCP gateway 1202. The CRCX 

15 message contains local connection options that are mapped 
from the AIP media capabilities information extracted from 
the IAM message into MGCP format. In line 4 of the call 
flow diagram, MGCP gateway 1202 sends an OK message 
to MGCP agent 1206. The OK message includes a media 

20 capability selected by MGCP gateway 1202 from the media 
capabilities specified in the CRCX message. The media 
description for the selected capability is returned in the SDP 
portion of the OK message. 

25 In line 5 of the call flow diagram, MGCP agent 1206 
sends an AIP call progress (CGP) message to H.323 agent 
1204. An AIP CPG message is used to signal events other 
than release and answer between protocol agents implement- 
ing different call halves. In the illustrated example, the CPG 

3Q message includes a mapping of the SDP portion of the OK 
message into AIP format. In addition, any other media 
capabilities which the MGCP agent is capable of supporting 
can be included in the media description. In line 6 of the call 
flow diagram, H.323 agent 1204 transmits an ALERTING 

35 message to H.323 endpoint 1200. H.323 agent 1204 maps 
the media description from the AIP CPG message into fast 
start parameters and includes the fast start parameters in the 
ALERTING message. Any additional capabilities that were 
received by the H.323 agent are stored for later usage. 

40 In line 7 of the call flow diagram, when the MGCP end 
user answers the call, signaling gateway 1202 sends a 
NOTIFY message to MGCP agent 1206. The NOTIFY 
message alerts MGCP agent 1206 of the off-hook event. In 
line 8 of the call flow diagram, in response to the NOTIFY 

45 message, MGCP agent 1206 transmits an AIP answer mes- 
sage (ANM) to H.323 agent 1204. 

In line 9 of the call flow diagram, in response to the 
answer message, H.323 agent 1204 transmits a CONNECT 
message to H.323 endpoint 1200. In lines 10 and 11 of the 

50 call flow diagram, H.323 endpoint 1200 and H.323 agent 
1204 exchange master/slave and master/slave acknowledge 
messages. These messages are sent according to H.245 
master/slave determination. This determination is made to 
resolve conflicts in media formats. H.323 agent 1204 

55 handles the exchange and does not map the exchange to the 
agent interworking protocol. 

In line 12 of the call flow diagram, H.323 endpoint 1200 
transmits an H.245 terminal capabilities set (TCS) message 
to H.323 agent 1204 to communicate the media capabilities 

60 of endpoint 1200 to H.323 agent 1204. In line 13, H.323 
agent 1204 acknowledges the TCS message. In line 14 of the 
call flow diagram, H.323 agent 1204 transmits a multipart 
message to MGCP agent 1206. The multipart message 
includes the capabilities of the H.323 device mapped into 

65 AIP format. The capabilities are sent to MGCP agent 1206 
in the AIP CPG message. Optionally, the H.245 representa- 
tion of the TCS can be sent as well. In this case, a multipart 
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message is sent between call halves. The multipart message 
includes both the AIP CPG message and the H.245 TCS 
message. Because MGC 1206 might not support H.245 TCS, 
MGCP agent 1206 might, i.e., if H.245 TCS is not 
supported, discard the TCS portion of the multipart message 
and process only the AIP portion. 

In lines 15 and 16 of the call flow diagram, H.323 
endpoint 1200 and H.323 agent 1204 exchange TCS and 
TCS ACK messages. In this exchange, the capabilities of the 
other end, i.e., of MGCP gateway 1202, which were received 
and stored upon receipt of the CPG message in line 5 of the 
call flow diagram, are sent to H.323 endpoint 1200 as an 
H.245 terminal capability set. 

H.323 Non-Fast Start to MGCP 

While FIG. 12 illustrated H.323 to MGCP interworking 
for H.323 fast start procedures, FIG. 13 illustrates H.323 to 
MGCP interworking without fast start procedures. In other 
words, in FIG. 13, the H.323 media capabilities are not 
exchanged until after call establishment. The entities 
involved in communications in FIG. 13 are the same as those 
illustrated in FIG. 12. Thus, a description of these entities is 
not repeated herein. 

Referring to FIG. 13, in line 1 of the call flow diagram, 
H.323 endpoint 1200 sends a SETUP message to H.323 
agent 1204. The SETUP message does not include fast start 
parameters. In line 2 of the call flow diagram, H.323 agent 
1204 transmits an AIP LAM message to MGCP agent 1206. 
The IAM message contains no media description. In other 
words, the connection information parameter is either not 
included or set to a null value. In line 3 of the call flow 
diagram, MGCP agent 1206 transmits a CRCX message to 
MGCP gateway 1202. The CRCX message can optionally 
contain a default set of media capabilities that do not reflect 
capabilities supported by the H.323 endpoint. A CRCX 
message example is as follows: 

CRCX: 

R: HD 

L: Default media capabilities 

M: Inactive (or receive only) 
In the CRCX message example, the hd value in the R field 
instructs gateway 1202 to go off-hook. The value in the L 
field specifies local connection options, which indicate to 
gateway 1202 the media capabilities of H.323 endpoint 
1200. In response to the CRCX message, in line 4 of the call 
flow diagram, MGCP gateway 1202 transmits an OK mes- 
sage to MGCP agent 1206. The OK message includes an 
SDP portion with the media description for the connection. 
An exemplary media description is as follows: 

v=0 

c=IP address 

m=media description 
In the exemplary media description set forth above, the IP 
address in the c=parameter is the IP address on MGCP 
gateway 1202 for receiving the media stream. The media 
description specified in the m=parameter includes the type 
of media that the media gateway is capable of receiving, e.g., 
voice, data, or video. 

In line 5 of the call flow diagram, MGCP agent 1206 
transmits an AIP call progress (CPG) message to H.323 
agent 1204. The AIP CPG message includes the connection 
information parameter data structure in which the media 
description from the SDP portion of the AIP message is 
mapped into AIP format. The media description is stored by 
H.323 agent 1204, but is not transmitted to H.323 endpoint 
1200 as a fast start parameter. 
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In line 6 of the call flow diagram, H.323 agent 1204 
transmits an ALERTING message to H.323 endpoint 1200. 
The ALERTING message notifies H.323 endpoint 1200 that 
the MGCP end user is being alerted. When the MGCP end 

5 user answers the call, in line 7 of the call flow diagram, 
MGCP gateway 1202 transmits a NOTIFY message to 
MGCP agent 1206. In line 8 of the call flow diagram, MGCP 
agent 1206 transmits an AIP answer message (ANM) to 
H.323 agent 1204. In line 9 of the call flow diagram, H.323 

10 agent 1204 transmits a CONNECT message to H.323 end- 
point 1200. In lines 10 and 11 of the call flow diagram, the 
H.245 master/slave determination takes place. H.323 agent 
1204 handles the exchange and does not map the exchange 
to the agent interworking protocol. 

15 In lines 12 and 13 of the call flow diagram H.323 endpoint 
1200 and H.323 agent 1204 exchange H.245 TCS and H.245 
TCS ACK messages. This exchange communicates the 
media capabilities of H.323 endpoint 1200 to H.323 agent 
1204. In line 14 of the call flow diagram, H.323 agent 1204 

20 transmits a multipart message to MGCP agent 1206. H.323 
agent 1204 maps the capabilities of H.323 endpoint 1200 
into AIP format and includes these capabilities in an AIP 
CPG message. Optionally, the H.245 representation of the 
TCS can be sent as well. In this example, a multipart 

25 message is sent that includes both the AIP CPG message and 
the H.245 TCS message. Since MGCP agent 1206 can not 
support H.245 TCS, MGCP agent 1206 can only process the 
AIP portion of the multipart message. 

In lines 15 and 16 of the call flow diagram, H.323 

30 endpoint 1200 and H.323 agent 1204 exchange TCS and 
TCS ACK messages. In this exchange, the capabilities of 
MGCP gateway 1202, which were received and stored upon 
receipt of the AIP CPG message in line 5 of the call flow 
diagram, are sent to H.323 endpoint 1200 as an H.245 

35 terminal capability set. In lines 17-20 of the call flow 
diagram, H.323 endpoint 1200 and H.323 agent 1204 
exchange H.245 OPEN LOGICAL CHANNEL and H.245 
OPEN LOGICAL CHANNEL ACKNOWLEDGE mes- 
sages. In this exchange, H.323 agent 1204 two unidirec- 

40 tional media streams between the end users. H.323 endpoint 
1200 returns its RTP port for each media stream in the 
acknowledge messages. 

In line 21 of the call flow diagram, H.323 agent 1204 
transmits an AIP CPG message to MGCP agent 1206. CPG 

45 message contains an updated media description to reflect the 
RTP address of H.323 endpoint 1200 and the mode change 
to send receive. In line 22 of the call flow diagram, MGCP 
agent 1206 transmits a modify connection message to 
MGCP gateway 1202. This updates the media description at 

50 MGCP gateway 1202 and a full duplex media path between 
end users is complete. 

H.323— NAQ.931 Call Hold Scenario 
FIG. 14 illustrates interworking between an H.323 end- 

55 point and an NAQ.931 device for a call hold scenario. In 
FIG. 14, it is assumed that a bi-directional media stream has 
been established between H.323 endpoint 1200 and 
NAQ.931 device 1400. H.323 endpoint 1200 can be an IP 
terminal, as previously described with respect to FIG. 12. 

60 NAQ.931 device 1400 can comprise an IP terminal. H.323 
agent 1402 includes interworking agent capabilities as well 
as H.323 gatekeeper capabilities. Similarly, NAQ.931 agent 
1404 includes interworking agent capabilities as well as 
NAQ.931 agent capabilities. 

65 In line 1 of the call flow diagram, NAQ.931 device 1400 
transmits a HOLD message to NAQ.931 agent 1404. In line 
2 of the call flow diagram, in response to the HOLD 
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message, NAQ.931 agent 1404 transmits an AIP CPG mes- In line 10 of the call flow diagram H.323 agent 1402 

sage to H.323 agent 1402. The CPG message includes the transmits an OPEN LOGICAL CHANNEL ACKNOWL- 

connection information parameter data structure. The chan- EDGE message to H.323 endpoint 1200 acknowledging the 

nel operation field in the data structure is set to mode change, opening of logical channel 1. In line 11 of the call flow 

and the mode field in the data structure is set to inactive. In 5 diagram, H.323 agent 1402 transmits an H.245 OPEN 

line 3 of the call flow diagram, H.323 agent 1402 transmits LOGICAL CHANNEL message to H.323 endpoint 1200 to 

a TCS=0 message to H.323 endpoint 1200. In line 4 of the open logical channel 2. In line 12 of the call flow diagram, 

call flow diagram, H.323 agent 1402 transmits a CLOSE H.323 endpoint 1200 transmits an H.245 OPEN LOGICAL 

LOGICAL CHANNEL message to H.323 endpoint 1200. CHANNEL ACKNOWLEDGE message to H.323 agent 

The CLOSE LOGICAL CHANNEL message doses one of 10 1402. In line 13 of the call flow diagram, H.323 agent 1402 

the two channels between H.323 endpoint 1200 and transmits an AIP CPC message to NAQ.931 agent 1404. The 

NAQ.931 device 1400. In line 5 of the call flow diagram, CPG message includes the connection information param- 

NAQ.931 agent 1404 transmits a FACILITY message to eter data structure. The channel operation field in the data 

NAQ.931 device 1400. The FACILITY message indicates structure is set to mode change and the mode field is set to 

that inactive mode has been entered. In line 6 of the call flow 15 send/receive. In line 14 of the call flow diagram, NAQ.931 

diagram, H.323 endpoint 1200 transmits a CLOSE LOGI- agent 1404 transmits a FACILITY message to NAQ.931 

CAL CHANNEL ACKNOWLEDGE message to H.323 device 1400. The FACILITY message includes a mode field 

agent 1402 acknowledging the closing of logical channel 1. that sets the mode to be send/receive. Once this message is 

In lines 7 and 8 of the call flow diagram, H.323 endpoint received, both logical channels are open between H.323 

1200 and H.323 agent 1402 exchange H.245 CLOSE LOGI- 20 endpoint 1200 and NAQ.931 device 1400. 


CAL CHANNEL and CLOSE LOGICAL CHANNEL 
ACKNOWLEDGE messages for logical channel 2. Once 

al channel 2 is closed, in line 9 of the call flow diagram FIG - 16 illustrates interworking for an H.323— MGCP 


H.323— MGCP Hold Scenario 

; Uustrates interworking for an H, 

H323 agent 1402 transmits an AIP CPG message to hold scenario. In FIG. 16, it is assumed that a 

NAQ.931 agent 1404. The AIP CPG message includes the 25 established between H.323 endpoint 1200 and MGCP device 

connection information parameter. The change operation 1600 ' MGCP device 1600 is assumed to support an event 

field in the connection information parameter data structure package for call hold and retrieve events. H.323 device 1200 

is set to mode change, and the mode is set to inactive. ^ the same as H - 323 device 1200 described with respect to 

FIG. 12, and hence a description thereof is not repeated 

H.323— NAQ.931 Call Retrieve Scenano 3Q herein MGC p device im can be ^ MGCp device> such as 

FIG. 15 illustrates H.323 to NAQ.931 interworking for a a media gateway. MGCP agent 1602 includes interworking 

call retrieve scenario. The entities illustrated in FIG. IS are agent functionality as well as MGCP media gateway con- 

the same as those illustrated in FIG. 14. Hence, a description trailer functionality. H.323 agent 1402 is the same as H.323 

thereof is not repeated herein. In FIG. 15, it is assumed that agent 1402 described with respect to FIG. 14, and hence a 

a call between H.323 endpoint 1200 and NAQ.931 device 35 description thereof is not repeated herein. 

1400 has been put on hold. Thus, the signaling that must In line 1 of the call flow diagram, MGCP device 1600 

occur between H.323 endpoint 1200 and NAQ.931 device transmits a NOTIFY message to MGCP agent 1602. The 

1400 to retrieve the call includes reopening the logical NOTIFY message includes an event that informs MGCP 

channels between H.323 endpoint 1200 and NAQ.931 agent 1602 that the end user connected to MGCP device 

device 1400. 40 1600 has placed the call on hold. In line 2 of the call flow 

In line 1 of the call flow diagram illustrated in FIG. 15, diagram, MGCP agent 1602 transmits an AIP CPG message 

NAQ.931 device 1400 transmits a RETRIEVE message to to H.323 agent 1402. The AIP CPG message includes the 

NAQ.931 agent 1404. In line 2 of the call flow diagram, connection information parameter. The channel operation 

NAQ.931 agent 1404 transmits an AIP CPG message to field in the connection information parameter data structure 

H.323 agent 1402. The CPG message includes the connec- 45 is set to mode change and the mode field is set to inactive, 

tion information parameter data structure with the change In line 3 of the call flow diagram, H.323 agent 1402 

operation field set to mode change and the mode set to transmits a TCS-0 message to H.323 endpoint 1200. 

send/receive. In lines 3 and 4 of the call flow diagram, the In lines 4 and 5 of the call flow diagram, H.323 endpoint 

H.245 master/slave determination occurs between H.323 1200 and H.323 agent 1402 exchange CLOSE LOGICAL 

endpoint 1200 and H.323 agent 1402. H.323 endpoint 1200 50 CHANNEL messages to close the logical channel between 

and H.323 agent 1402 must revert to a TCS exchange in H.323 endpoint 1200 and MGCP device 1600. In line 6 of 

order to reestablish the media streams. Accordingly, in lines the call flow diagram, MGCP agent 1602 transmits a 

5 and 6 of the call flow diagram H.323 endpoint 1200 and MODIFY connection (MDCX) message to MGCP device 

H.323 agent 1402 exchange TCS and TCS ACK messages. 1600 indicating that the mode has been set to inactive. In 

In line 7 of the call flow diagram H.323 endpoint 1200 55 lines 7 and 8 of the call flow diagram, H.323 endpoint 1200 

transmits an H.245 OPEN LOGICAL CHANNEL to H.323 and H.323 agent 1402 exchange the messaging required to 

agent 1402. In line 8 of the call flow diagram, H.323 agent close logical channel 2. H.323 agent 1402 interprets the 

1402 transmits an AIP CPG message to NAQ.931 agent inactive mode as a hold and applies H.323 third party calls 


1404. The CPG message includes the connection informa- and rerouting procedures to implement the hold actions, 

tion parameter data structure. The channel operation field 60 These procedures result in the closing of both unidirectional 

and the data structure is set to mode change and the mode is media streams between H.323 endpoint 1200 and MGCP 

set to send only. This reestablishes one of the media streams device 1600. In line 9 of the call flow diagram, H.323 agent 

between H.323 endpoint 1200 and NAQ.931 device 1400. In 1402 transmits an AIP CPG message to MGCP agent 1602. 

fine 9 of the call flow diagram, NAQ.931 agent 1404 The CPG message includes the connection information 

transmits a FACILITY message to NAQ.931 device 1400. 65 parameter data structure. The channel operation field in the 

The FACILITY message includes a mode parameter that sets connection information data structure is set to mode change, 

the channel to be receive only. and the mode field is set to inactive. 
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H.323— MGCP Retrieve Scenario 

FIG. 17 illustrates an H.323— MGCP retrieve scenario. 
The entities illustrated in FIG. 17 are the same as those 
illustrated in FIG. 16, and hence a description thereof is not 
repeated herein. In FIG. 17, it is assumed that a call between 
H.323 endpoint 1200 and MGCP device 1600 has been 
placed on hold. 

In line 1 of the call flow diagram, MGCP device 1600 
transmits a NOTIFY message to MGCP agent 1602. The 
NOTIFY message contains an event that indicates to MGCP 
agent 1602 that the end user connected to MGCP device 
1600 wishes to retrieve the call. In line 2 of the call flow 
diagram, MGCP agent 1602 transmits an AIP CPG message 
to H.323 agent 1402. The AIP CPG message includes the 
connection information parameter data structure. The chan- 
nel operation field in the data structure is set to mode change, 
and the mode field is set to send/receive. 

In lines 3 and 4 of the call flow diagram, H.323 agent 1402 
and H.323 endpoint 1200 make a master/slave determina- 
tion. The H.323 devices must revert to a TCS exchange in 
order to reestablish the media streams. Accordingly, in lines 
5 and 6 of the call flow diagram, H.323 agent 1402 and 
H.323 endpoint 1200 exchange terminal capabilities. 

In line 7 of the call flow diagram, H.323 endpoint 1200 
transmits an H.245 open logical channel message to H.323 
agent 1402 to open one of the logical channels between 
H.323 endpoint 1200 and MGCP device 1600. In line 8 of 
the call flow diagram, H.323 agent 1402 transmits an AIP 
CPG message to MGCP agent 1602. The AIP CPG message 
includes the connection information parameter data struc- 
ture. The change operation field in the data structure is set to 
mode change, and the mode field is set to send only. In line 
9 of the call flow diagram, MGCP agent 1602 transmits a 
modify connection message to MGCP device 1600. The 
modify connection message includes a mode field setting the 
mode to receive only. In line 10 of the call flow diagram 
H.323 agent 1402 acknowledges the H.245 open logical 
channel messages transmitted in line 7 of the call flow 
diagram. 

In lines 11 and 12 of the call flow diagram, H.323 
endpoint 1200 and H.323 agent 1402 exchange messaging 
for opening the other logical channel between H.323 end- 
point and MGCP device 1600. In line 13 of the call flow 
diagram, H.323 agent 1402 transmits an AIP CPG message 
to MGCP agent 1602. The CPG message includes the 
connection information parameter data structure. The chan- 
nel operation field in the data structure is set to mode change, 
and the mode field is set to send/receive. In line 14 of the call 
flow diagram, MGCP agent 1602 transmits a modify con- 
nection message to MGCP device 1600. The modify con- 
nection message instructs the device to change the mode to 
send/receive. At this point, both media streams between 
H.323 endpoint 1200 and MGCP device 1600 are estab- 


H.323 to MGCP Primary Rate Interface (PRI) 
Common Channel Signaling (CCS) 
FIG. 18 illustrates exemplary call signaling for H.323 to 60 
MGCP PRI (CCS). In FIG. 18, signaling gateway 1800 
relays call control signaling between a circuit-switched 
network and a packet-switched network. For example, sig- 
naling gateway 1800 may be connected to a PSTN end office 
on one side and to an IP network on the other side. In the 65 
illustrated embodiment, signaling gateway 1800 is config- 
ured to forward Q.931 call signaling messages from the 
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PSTN network to a packet network and vice-versa. On the 
circuit-switched side, SG 1800 can be configured to send 
and receive Q.931 over Q.921 call signaling messages. On 
the packet-switched side, signaling gateway 1800 can be 

5 configured to send and receive Q.931 over ISDN User 
Adaptation over TCP/IP messages. 

Media gateway 1802 converts between packets and cir- 
cuits to communicate the media stream to and from a PSTN 
end user device. On the circuit-switched side, media gate- 

0 way 1802 can send and receive the media stream using pulse 
code modulation (PCM) voice. On the packet-switched side, 
media gateway 1802 can send and receive the media stream 
using RTP over UDP/IP. In the illustrated embodiment, 
media gateway 1802 is controlled using MGCP. 

5 CCS agent 1804 exchanges call control information with 
signaling gateway 1800 and media control information with 
media gateway 1802. In the illustrated embodiment, CCS 
1804 communicates with signaling gateway 1800 using 
Q.931 call signaling over IUA over TCP/IP and with media 

0 gateway 1802 using MGCP. CCS agent 1804 also commu- 
nicates with H.323 agent 1806 using the agent interworking 
protocol, as described above. It is understood that CCS agent 
1804 and H.323 agent 1806 can be part of a call server. 
H.323 agent 1806 and H.323 gateway 1808 exchange call 

5 signaling information according to ITU Recommendation 
H.225. 

In line 1 of the call flow diagram, signaling gateway 1800 
transmits a SETUP message to CCS agent 1804. The SETUP 
Q message includes information, such as the dialed digits for 
creating a call with the called party. In line 2 of the call flow 
diagram CCS agent 1804 transmits a CALL PROCEEDING 
message to signaling gateway 1800 to indicate that CCS 
agent 1804 is attempting to establish a call with the called 
5 party. In line 3 of the call flow diagram, CCS agent 1804 
sends an MGCP CREATE CONNECTION message to 
media gateway 1802. In response to the CREATE CON- 
NECTION message, media gateway 1802 transmits an 
ACKNOWLEDGE message including an SDP portion that 
0 specifies the supported media capabilities of media gateway 
1802. In fine 5 of the call flow diagram, CCS agent 1804 
transmits an AIP IAM message to H.323 agent 1806. The 
AIP IAM message includes the connection information 
parameter that specifies the supported media capabilities of 
5 media gateway 1802. In line 6 of the call flow diagram, 
H.323 agent 1806 transmits a SETUP message specifying 
the media capabilities of media gateway 1802 to H.323 to 
H.323 gateway 1808. In line 7 of the call flow diagram, 
H.323 gateway agent 1808 transmits an ALERT message to 
0 H.323 agent 1806 indicating that the called part is being 
alerted, of the incoming call. The ALERT message includes 
the supported media capabilities of H.323 gateway 1808. In 
line 8 of the call flow diagram, H.323 agent 1806 sends an 
AIP CALL PROGRESS message including the connection 
5 information parameter specifying the media description of 
H.323 gateway 1808. In line 9 of the call flow diagram, CCS 
agent 1804 transmits an ALERT message to signaling gate- 
way 1800 indicating that the called party is being alerted. 
In line 10 of the call flow diagram, CCS agent 1804 
o transmits an MGCP MODIFY CONNECTION message 
specifying the mode of the connection as receive only and 
including the media description of H.323 gateway 1808. In 
line 11 of the call flow diagram, media gateway 1802 
acknowledges the MODIFY CONNECTION message. 

In line 12 of the call flow diagram, when the called party 
answers the call, H.323 gateway 1808 transmits a CON- 
NECT message to H.323 agent 1806. In line 13 of the call 
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flow diagram, in response to receiving the CONNECT 
message, H.323 agent 1806 transmits an AIP ANSWER 
message to CCS agent 1804. In line 14 of the call flow 
diagram, CCS agent 1804 transmits a CONNECT message 
to signaling gateway 1800 indicating that the call has been 5 
answered. In line 15 of the call flow diagram, CCS agent 
1804 transmits a MODIFY CONNECTION message to 
media gateway 1802 opening the connection as send/ 
receive. In line 16 of the call flow diagram, media gateway 
1802 acknowledges the MODIFY CONNECTION message. 
At this point, a bi-directional media stream communication 
is established between the called and calling parties. Thus, 
the call flow diagram illustrated in FIG. 18 embodies the true 
MGCP reference architecture whereby the SG and MG are 
separate entities. 

MGCP— H.323 Call Setup and Exchange of DTMF " 
Digits 

FIG. 19 illustrates call signaling and exchange of DTMF 
digits between an MGCP gateway and an H.323 gateway. 
The entities illustrated in FIG. 19 are the same as those 20 
illustrated in FIG. 16. Hence, a description thereof is not 
repeated herein. 

In FIG. 19 it is assumed that a connection has already 
been established between H.323 endpoint 1200 and MGCP 
device 1600. Therefore, call setup and teardown messages ^ 
are not shown. 

In line 1 of the call flow diagram, H.323 endpoint 1200 
transmits a user input indication message to H.323 agent 
1402 that includes the DTMF digit * encoded in the mes- 
sage. In line 2 of the call flow diagram, H.323 agent 1906 
transmits an AIP_INFO message to MGCP agent 1602 that 
indicates that information is being communicated to MGCP 
agent 1602. The AIP_INFO message includes the digit 
information parameter that specifies the DTMF digit entered 
by the end user connected to H.323 gateway 1902. In line 3 3J 
of the call flow diagram, MGCP agent 1602 transmits a 
MODIFY CONNECTION message to MGCP device 1600. 
The modify connection message includes a signal indicating 
the DTMF digit *. In line 4 of the call flow diagram, MGCP 
device 1600 acknowledges the modify connection message. 4Q 
The remaining messages in FIG. 19 are similar to the 
messages described with respect to lines 1-4 of the call flow 
diagram. Hence, a description thereof is not repeated herein. 

It will be understood that various details of the invention 
can be changed without departing from the scope of the 45 
invention. Furthermore, the foregoing description is for the 
purpose of illustration only, and not for the purpose of 
limitation — the invention being defined by the claims. 

What is claimed is: 

1. A call server comprising: so 

(a) a fist protocol agent for communicating with a first 
internet protocol (IP) telephony device according to a 
first IP telephony protocol; 

(b) a second protocol agent for communicating with a 
second IP telephony device according to a second IP 55 
telephony protocol; and 

(c) an interworking agent for providing functions usable 
by the first and second protocol agents to communicate 
with each other according to a third protocol, the 
functions provided by the third protocol being a super- 60 
set of functions provided by the first and second IP 
telephony protocols, said interworking agent further 
adapted to determine that a first parameter associated 
with the first IP telephony protocol does not map to the 
second IP telephony protocol and communicating first 65 
parameter to the second protocol agent without alter- 
ation. 
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2. The call server of claim 1 wherein the interworking 
agent comprises a first interworking agent component asso- 
ciated with the first protocol agent and a second interwork- 
ing agent component associated with the second protocol 
agent. 

3. The call server of claim 1 wherein the first protocol 
agent is a media gateway control protocol (MGCP) agent, 
the first IP telephony protocol is MGCP, the second protocol 
agent is an International Telecommunications Union (ITU) 
Recommendation H.323 agent, and the second IP telephony 
protocol is H.323. 

4. The call server of claim 1 wherein the first protocol 
agent is an International Telecommunications Union Rec- 
ommendation H.323 agent, the first IP telephony protocol is 
11323, the second protocol agent is a session initiation 
protocol (SIP) agent, and the second IP telephony is SIP. 

5. The call server of claim 1 wherein the first protocol 
agent is an International Telecommunications Union Rec- 
ommendation H.323 agent, the first IP telephony protocol is 
H.323, the second protocol agent is a Bellcore Q.931 agent, 
and the second IP telephony protocol is an extension of 
Bellcore Q.931. 

6. The call server of claim 1 wherein the first protocol 
agent is a media gateway control protocol (MGCP) agent, 
the first IP telephony protocol is MGCP, the second protocol 
agent is a media gateway control protocol (MGCP) agent, 
and the second IP telephony protocol is MGCP. 

7. The call server of claim 1 wherein the first protocol 
agent is an International Telecommunications Union Rec- 
ommendation H.323 agent, the first IP telephony protocol is 
H.323, the second protocol agent is an H.323 agent, and the 
second IP telephony protocol is H.323. 

8. The call server of claim 1 wherein the first protocol 
agent performs originating call half functions and the second 
protocol agent performs terminating call half functions. 

9. The call server of claim 1 wherein the interworking 
agent is adapted to provide a connection information param- 
eter data structure usable by the first and second protocol 
agents, for communicating media capabilities and media 
stream management information between the first and sec- 
ond protocol agents. 

10. The call server of claim 1 wherein the interworking 
agent is adapted to provide a digit information parameter 
usable by the first and second protocol agents for commu- 
nicating dual tone multifrequency (DTMF) digits between 
the first and second protocol agents. 

11. A method for interworking devices that communicate 
using different internet protocol (IP) telephony protocols, 
the method comprising: 

(a) receiving, from a first telephony device, a first mes- 
sage formatted according to a first IP telephony proto- 
col; 

(b) in response to receiving the first message, generating 
a second message, formatted according to a second 
protocol, said second protocol being distinct from said 
first protocol, the second message including at least one 
of a media capabilities description and media stream 
management information derived from the first mes- 
sage; 

(c) transmitting the second message to a second protocol 
agent; and 

(d) in response to receiving the second message, gener- 
ating a third message formatted according to a third IP 
telephony protocol, the third message including at least 
one of the media capabilities description and media 
stream management information derived from the sec- 
ond message. 
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12. The method of claim 11 wherein receiving a first 
message includes receiving the first message formatted 
according to the media gateway control protocol (MGCP) 
and generating a third message includes generating the third 
message formatted according to ITU Recommendation 
H.323. 

13. The method of claim 11 wherein receiving a first 
message includes receiving the first message formatted 
according to the session initiation protocol (SIP) and gen- 
erating a third message includes generating the third mes- 
sage formatted according to ITU Recommendation H.323. 

14. The method of claim 11 wherein receiving a first 
message includes receiving the first message formatted 
according to ITU Recommendation H.323 and generating a 
third message includes generating the third message format- 
ted according to Bellcore Q.931. 

15. The method of claim 11 wherein receiving a first 
message includes receiving the first message formatted 
according to ITU Recommendation H.323 and generating a 
third message comprises generating the third message for- 
matted according to media gateway control protocol 
(MGCP). 

16. The method of claim 15 wherein receiving the first 
message formulated to ITU Recommendation H.323 
includes receiving the first message containing H.323 fast 
start parameters, wherein generating a second message 
include mapping the H.323 fast start parameters to a media 
capabilities description in the second message, and gener- 
ating the third message includes mapping the media capa- 
bilities description to MGCP. 

17. The method of claim 11 wherein receiving a first 
message includes receiving a HOLD message from the first 
telephony device, generating the second message includes 
generating a message including a connection information 
parameter having a mode change value for changing the 
mode of a media stream communication associated with the 
first telephony device, and wherein generating a third mes- 
sage includes generating a message for changing the mode 
of the media stream communication to inactive according to 
the third IP telephony protocol. 

18. The method of claim 11 wherein receiving a first 
message includes receiving a RETRIEVE message from the 
first telephony device, and generating a second message 
includes generating a message including a connection infor- 
mation parameter having a mode change value of active. 

19. The method of claim 11 wherein receiving a first 
message includes receiving a first message including at least 
one dual tone multifrequency (DTMF) digit value, generat- 
ing a second message includes mapping the DTMF digit 
value to a digit information parameter value in the second 
protocol, and generating a third message includes mapping 
the digit information parameter value to a DTMF digit value 
formatted according to the third IP telephony protocol. 

20. The method of claim 11 comprising transmitting the 
third message to a second telephony device configured to 
communicate according to the third IP telephony protocol. 

21. A method for tunneling messages between protocol 
agents, the method comprising: 

(a) receiving, from a first telephony device, a first mes- 
sage formatted according to a first IP telephony proto- 

(b) determining whether a parameter in the first message 
maps to a second IP telephony protocol; 
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(c) in response to determining that the parameter in the 
first message maps to the second IP telephony protocol, 
formulating a second message formatted according to 
the second IP telephony protocol; and 

(d) in response to determining that the parameter in the 
first message does not map to the second IP telephony 
protocol, transmitting the first message without alter- 
ation to a second protocol agent. 

22. A method for tunneling messages between protocol 
10 agents, the method comprising: 

receiving, from a first telephony device, a first message 

formatted according to a first IP telephony protocol; 
determining whether a parameter in the first message 
15 maps to a second IP telephony protocol; 

in response to determining that the parameter in the first 
message maps to the second IP telephony protocol, 
formulating a second message formatted according to 
the second IP telephony protocol; 
20 in response to determining that the parameter in the first 
message does not map to the second IP telephony 
protocol, transmitting the first message without alter- 
ation to a second protocol agent, and 
in response to determining that the parameter in the first 
25 message partially maps to the second IP telephony 
protocol, formulating a multiprotocol message, the 
multiprotocol message including a message formatted 
according to the first IP telephony protocol and a third 
message formatted to the second IP telephony protocol. 
30 23. The method of claim 22 comprising transmitting the 
multiprotocol message to a second protocol agent. 

24. The method of claim 23 comprising in response to 
receiving the multiprotocol message, dividing the multipro- 
tocol message into the second and third messages. 
35 25. The method of claim 24 comprising after dividing the 
multiprotocol message, determining whether processing of 
the second message is supported by the second IP telephony 
protocol agent, and in response to determining that the 
40 processing of the second message is supported, processing 
the second message. 

26. The method of claim 25 comprising processing the 
third message. 

27. A computer program product comprising computer- 
45 executable instructions embodied in a computer readable 

medium for performing steps comprising: 

invoking a first protocol agent for communicating with a 
first internet protocol (IP) telephony device according 
to a first IP telephony protocol; 
50 invoking a second protocol agent for communicating with 
a second IP telephony device according to a second IP 
telephony protocol; 
mapping media capabilities information extracted from 
5J messages received from the first and second IP tele- 
phony devices formatted according to the first and 
second IP telephony protocols to a third protocol; 
transmitting a first message containing the media capa- 
bilities information and formatted according to the third 
60 protocol between the first and second protocol agents; 
determining whether a parameter from the first IP tele- 
phony protocol maps to the second IP telephony pro- 
tocol; and 

in response to said determining that the parameter from 
65 the first IP telephony protocol does not map to the 
second IP telephony protocol, transmitting the param- 
eter without alteration to the second protocol agent. 
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28. The computer program product of claim 27 wherein 
invoking a first protocol agent includes invoking a first 
protocol agent for performing originating call functions and 
invoking a second protocol agent includes invoking a second 
protocol agent for performing terminating call functions. 

29. The computer program product of claim 27 compris- 
ing at the first protocol agent, mapping media stream infor- 
mation received from the second protocol agent to the first 
IP telephony protocol. 

30. The computer program product of claim 27 1 
comprising, at the second protocol agent, mapping media 
stream information received from the first protocol agent to 
the second IP telephony protocol. 

31. The computer program product of claim 27 wherein i 
the first IP telephony protocol is the media gateway control 
protocol and the second IP telephony protocol is ITU 
Recommendation H.323. 

32. The computer program product of claim 27 wherein 
the first IP telephony protocol is ITU Recommendation 2 
H.323 and the second IP telephony protocol is Bellcore 
Q.931. 

33. The computer program product of claim 27 wherein 
the first IP telephony protocol is the session initiation 
protocol and the second IP telephony protocol is ITU 2 
Recommendation H.323. 


34. A computer readable medium having software stored 
thereon, said software comprising; 

a fist protocol agent for communicating with a first 
internet protocol (IP) telephony device according to a 
first IP telephony protocol; 

a second protocol agent for communicating with a second 
internet protocol telephony device according to a sec- 
ond IP telephony protocol, wherein said second IP 
telephony protocol is distinct from said first IP tele- 
phony protocol; 

a third protocol agent for communicating with a third 
internet protocol telephony device according to a third 
IP telephony protocol, wherein said third IP telephony 
protocol is distinct from said first and second IP tele- 
phony protocols; and 

an interworking protocol adapted to represent a partial 
superset of messaging capabilities of said first, second, 
and third IP telephony protocols such that messages 
received in any of said first, second, or third IP tele- 
phony protocols from a first IP device are converted to 
said interworking protocol and then translated into a 
different one of said first, second, or third IP telephony 
protocols for transmission to a second IP device. 
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